Форум MySQL

Есть ли вариация http://www.mysql.ru/docs/man/MySQL_indexes.html ? Я согласен - хорошая, достаточно полная... но написано это каким-то таким языком... который не оседает во мне. Есть ли что-то иное по этой теме? Я очень хочу разобраться с индексами.
Суть - ясна, конечно. Но вот подробности - нет.

Что не понятно?

PS Мануал пишется из расчёта, что вам всё известно об MySQL и вам нужен только справочник - это не всегда удобно. Кроме того, он претерпевает перевод со шведского на английский и с английского на русский в результате иногда смысл теряется...

Все индексы MySQL (PRIMARY, UNIQUE, и INDEX) хранятся в виде B-деревьев
Что такое B-деревья?

Однако в случае, когда необходим доступ почти ко всем 1000 строкам, быстрее будет последовательное чтение
Так как же разобраться - необходим ли доступ ко всем строкам или нет? У меня уйма строк. Из них уйма попадает под WHERE, но эта уйма - меньше половины. И что же делать? И потом - что если это изменяемо? Сегодня под WHERE попало 80% строк, а завтра - 2% ... Не могу же я каждый день бегать и менять индексы в таблице.

Если эти операции делаются на крайнем слева префиксе используемого ключа (например ORDER BY key_part_1,key_part_2). Если за всеми частями ключа следует DESC, то данный ключ читается в обратном порядке
Надо ли говорить, что это для меня - шумерская грамота? Я перечитывал этот абзац восемь раз...

Если по столбцам col1 и col2 существует многостолбцовый индекс, то соответствующие строки могут выбираться напрямую. В случае, когда по столбцам col1 и col2 существуют раздельные индексы, оптимизатор пытается найти наиболее ограничивающий индекс путем определения, какой индекс найдет меньше строк, и использует данный индекс для выборки этих строк.
Это относится к шумерской грамоте версии 2...



Пониже там примерно такие же трудности... но я не буду их сюда ставить - если пойму хотя бы то, что написал выше - уже отлично будет.
Порой приходится изучать программирование с другой стороны... Не со стороны теории, документации и справочников - а со стороны практики. Это и сложнее, и легче одновременно... это просто иначе. Но подобные мануалы рассчитаны именно на тех людей, кто изучал по книгам. Кто подошел к этим мануалам уже зная. Но другому слою программистов приходится подходить к этим мануалам как к учебникам, а не как к мануалам. Просто по-необходимости... Вы сами как-то мне сказали, что переходить на новую версию серверного софта нужно только по мере необходимости. На самом деле этот совет верен и в отношении знаний. Их нужно получать по мере необходимости. Вот сейчас у меня и возникла такая необходимость - разобраться с индексами. Но информация есть только двух направлений:

а) мануалы (выше я написал, почему они не подходят... да и вы написали...)
б) обсуждения о пользе индексов... без грамма нужной информации.

Под B-деревьями скрываются бинарные деревья - эту захватывающую информацию можно пропустить мимо без всякого ущерба для использования - вы всё равно повлиять на алгоритм поиска не сможете. Проблема в том, что мануал пишут разработчики и они к сожалению пишут не то, что требуется пользователям (для них это очевидно), а что им самим интересно, поэтому местами мануал пародаксален - есть места вообще лишённые смысла... нужно просто набраться терпения и относится к информации более критически.

Если эти операции делаются на крайнем слева префиксе используемого ключа (например ORDER BY key_part_1,key_part_2). Если за всеми частями ключа следует DESC, то данный ключ читается в обратном порядке
Эти подробности тоже интересны скорее разработчикам - смысл тот, что при DESC поиск начинается с конца, а не с начала. Можете пропускать это мимо ушей - повлиять вы на это всё равно не сможете.

Если по столбцам col1 и col2 существует многостолбцовый индекс, то соответствующие строки могут выбираться напрямую. В случае, когда по столбцам col1 и col2 существуют раздельные индексы, оптимизатор пытается найти наиболее ограничивающий индекс путем определения, какой индекс найдет меньше строк, и использует данный индекс для выборки этих строк.
Переводы ещё достаточно кривые, хотя английский мануал красноречием тоже не блещет. Смысл это фразы сводится к тому, что если столбцы col1 и col2 проиндексированы отдельно, а MySQL встречает запрос

SELECT * FROM tbl WHERE col1 = 45 AND col2=1456

то оптимизатор проверит сначала сколько уникальных значений столбца col1 и col2 и начнёт искать с того столбца, для которого возвращается меньше значений, так как чем меньше будет значений в промежуточном результате, тем быстрее в нём отыщется значение второго столбца. Вот эта информация уже интереснее означает она, что вам самому можно не заботится о порядке условий в WHERE - это хорошо, так как и других забот достаточно много...

Вообще философия индексов достаточно проста - если вы готовы пожертвовать дополнительным объёмом памяти, MySQL может попытаться работать с данными быстрее (как правило, очень успешно), однако следует помнить, что если индексировать что попало и по максимуму - объём базы данных вырастет на столько, что наступит замедление.
Ещё что следует знать разработчику, так это то, что индексы ускоряют работу операторов выборки (SELECT) и замедляют операции обновления данных (INSERT, UPDATE, DELTE).

Так это... последняя ваша фраза сводит на "нет" вообще всё... Мне INSERT, UPDATE, DELETE нужны более скоростные, чем SELECT. Выходит - все индексы надо вышвырнуть, кроме автоинкрементных, да unique ?

Да, и чем больше выкинете, тем будет быстрее работать - хотя для UPDATE тоже нужно производить поиск, но операция по вставке данных, как правило, перешибает по длительности все преимущества индексов.

В общем... спасибо..