Новичок
Покинул форум
Сообщений всего: 40
Дата рег-ции: Февр. 2010
Помог: 0 раз(а)
|
Всем привет!
Похоже, я уткнулся в необходимость плотной работы с базами данных. А это значит, надо вплотную заняться их оптимизацией.
Первое, что приходит в голову - расставить индексы. Но даже это оказалось не так просто! Какое-то погуглив-почитав в рунетах, я понял, что четкости в понимании MySQL-ных индексов у меня совершенно не прибавляется. Даже скорее наоборот.
Потому решил обратиться к опытным товарищам с просьбой расставить над ними точки.
Итак, что я понял (не факт, что правильно):
1. Индексы ускоряют работу БД.
2. Индекс - это отдельный файл, который хранится на жестком диске и занимает место. Соответственно, не стоит их плодить слишком много.
3. Индекс - это что-то типа предметного указателя, т.е. то же самое поле, что и в таблице, только сортированное, скажем, по алфавиту.
4. Индексы могут быть разными (primary key, unique, index, fulltext), при этом какие-то из них (видимо - первые два) уникальные, то есть не могут существовать две записи с одним значением индекса, а какие-то (оставшиеся два) - не уникальные.
5. Для полнотекстовых индексов можно указать какую часть текста индексировать.
6. Индекс может быть натуральным (несущим смысловую нагрузку) и суррогатным (служащим только для идентификации записи)
Ок. Что я не понял.
1. Почему-то все пишут только про уникальные индексы, некоторые даже открыто заявляют, что неуникальные индексы не имеют смысла. Это, на мой взгляд, странно. Скажем, у нас есть таблица с топиками и таблица с комментами к этим топикам. И нам нужно выбрать все комменты к топику 2834. Комментов с topic_id=2834 будет куча (скажем 77, а всего записей, скажем - 100500), и проще их искать по индексу. Не так ли? Да. и правильно ли я понимаю, что для этого поля индекс должен быть типа INDEX?
2. Почему-то все рекомендуют создавать суррогатный PRIMARY_KEY на любых таблицах. Я не понимаю, зачем. Скажем, в той же таблице с комментами к топику. Зачем нужно делать comment_id, если с отдельным комментом никаких операций производиться не должно? Соответственно, он никогда не будет участвовать в WHERE и т.п.
3. Чем PRIMARY_KEY отличается от UNIC? Я так понял, что тем, что PRIMARY_KEY может быть только один в таблице. А в чем смысл?
4. Когда нужно использовать многостолбцовые индексы? Я так понял, что тогда, когда гм.. записей с одинаковым индексом по первому столбцу становится слишком много?
5. Где-то слышал, что лучше иметь один суррогатный PRIMARY_KEY, чем многостолбцовый индекс. Что выглядит логично - проще работать с одной колонкой, чем с кучей. Но я опять же не понимаю: допустим, нам нужно удалить все комменты юзера user_id из топика topic_id. Конечно, можно удалить комменты за номерами 4, 56, 58, 71, и это будет быстро, если comment_id - PRIMARY_KEY. Но. Вначале ведь нужно их как-то найти, эти значения!
6. Опять же, допустим, может возникнуть удалить все комментарии одного юзера из одного топика, а может - все комментарии в топике после 22-х часов. Но ведь не делать же под каждый такой вариант свой многостолбцовый индекс!
Вот, как-то пока так...
|