http://softtime.ru/sql/?id_article=104
_____________
Стимулятор ~yoomoney - 41001303250491
Полная Версия: Индексы sql
| Цитата (Zzepish @ 6.03.2016 - 16:35) |
| Индексы должны идти с лева на право, как они у тебя расположенный в запросе |
Не учи плохому, учи хорошему! А плохо само получится...
Не важно совершенно, в каком порядке у тебя в запросе стоят условия. Важно наличие полей В ЗАПРОСЕ, а не их порядок. А вот порядок полей В ИНДЕКСЕ как раз важен. Если сделаешь "индекс1 (колонка1, колонка2)" или "индекс2 (колонка2, колонка1)", то очень легко можно получить очень разные скорости выборки (в зависимости от ряда условий).
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss
а индекы не формируются в итоге в таком стиле:
namelast_nameage
ArtenZzepish23
?
а индекы не формируются в итоге в таком стиле:
namelast_nameage
ArtenZzepish23
?
Zzepish, не понял твой вопрос.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss
Я про составной индекс. Если я правильно помню: они сливаются в одну строку в последовательности их назначения
Я про составной индекс. Если я правильно помню: они сливаются в одну строку в последовательности их назначения
Ещё один вопросик. Я так понял, что если сделать индекс одновременно на 3 колонки, то в запросе только на первую из них индекс также сработает?
_____________
Принимаю заказы, писать в ЛС
_____________
Принимаю заказы, писать в ЛС
| Цитата (Zzepish @ 7.03.2016 - 01:56) |
| Я про составной индекс. Если я правильно помню: они сливаются в одну строку в последовательности их назначения |
Нет, никуда они не сливаются. Почитай, что такое "бинарное дерево". Например тут http://www.k-press.ru/cs/2000/3/trees/trees.asp очень неплохо описано.
Если кратко, на верхнем уровне дерева находятся те данные, которые соответствуют первому полю индекса. На втором уровне - данные из второго поля. И так далее.
| Цитата (Медведь @ 7.03.2016 - 06:31) |
| Я так понял, что если сделать индекс одновременно на 3 колонки, то в запросе только на первую из них индекс также сработает? |
Да, так
И только на первую. И на первую-вторую, и на первую-вторую-третью... А вот на первую-третью не получится 
Если почитаешь по ссылке, что я дал на несколько строк выше в этом ответе, то поймешь. Ну или сам погугли по словам "индекс бинарное дерево".
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss
Я знаю про бинарное дерево. Я не знал про то, что таким образом построенна система индексов)
Я знаю про бинарное дерево. Я не знал про то, что таким образом построенна система индексов)
| Цитата (Zzepish @ 7.03.2016 - 11:47) |
| Вот тут прочел |
Бред какой-то там написан про составные индексы... Для "понимания в целом", может быть, и имеет смысл так объяснить. Но автор той "статьи", похоже, никогда не слышал о цифровых деревьях. И не понимает, как они используются при работе индексов.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss
Уточнил у нашего куратора - таки деревья)
Уточнил у нашего куратора - таки деревья)
Медведь
Дело в том, что когда ты делаешь выборку
Вариант когда индекс простой, т.е. только по [id] предполагает, что сначала поработаем с индексной таблицей, а затем перейдем к условию WHERE в основной таблице, даже если там одна строка, mysql как бы этого еще не знает выполняя условие
но ты правильно заметил, делая постоянный UPDATE для `time` с составным индексом придется еще и каждый раз делать внутренний UPDATE для индексной таблицы.
Я не уверен что это правильно и скорее склоняюсь к варианту с простым идексом по id.
И почему "ЗУБРЫ" форума с этим не согласны, не совсем понимаю.
Очень хотелось бы услышать комментарии.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Дело в том, что когда ты делаешь выборку
SELECT * FROM `tabel` WHERE `id`=1 AND `time`>345345435она идет слева направо, как ты понимаешь. И если у тебя индекс составной по полям [id+time], то MySQL заканчивает выборку сразу же на уровне таблицы индекса, не включая механизм перебора WHERE для основной таблицы.
Вариант когда индекс простой, т.е. только по [id] предполагает, что сначала поработаем с индексной таблицей, а затем перейдем к условию WHERE в основной таблице, даже если там одна строка, mysql как бы этого еще не знает выполняя условие
`id`=1
но ты правильно заметил, делая постоянный UPDATE для `time` с составным индексом придется еще и каждый раз делать внутренний UPDATE для индексной таблицы.
Я не уверен что это правильно и скорее склоняюсь к варианту с простым идексом по id.
И почему "ЗУБРЫ" форума с этим не согласны, не совсем понимаю.
Очень хотелось бы услышать комментарии.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
| Цитата (GET @ 8.03.2016 - 09:10) |
| но ты правильно заметил, делая постоянный UPDATE для `time` с составным индексом придется еще и каждый раз делать внутренний UPDATE для индексной таблицы. |
Так рассуждать, так лучше вообще индексы не использовать
Ведь на их обновление всегда тратится время.| Цитата (GET @ 8.03.2016 - 09:10) |
Я не уверен что это правильно и скорее склоняюсь к варианту с простым идексом по id. |
В данном случае, может быть, так и правильнее будет. Потому что если индекс пользователя уникальный, то тогда условие на время вообще бессмысленно. Выбираешь ту единственную запись и смотришь, какое у неё время. В этом случае, кстати, может быть нужно просто пересмотреть структуру БД?
Но тут еще дело в том, что в теме речь идет об индексах в целом, о том, как их лучше составлять и как они вообще работают.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
| Цитата |
| Так рассуждать, так лучше вообще индексы не использовать Ведь на их обновление всегда тратится время. |
я именно из-за этого и имел ввиду:
| Цитата |
| Потому что если индекс пользователя уникальный |
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.
Живой пример эффективности составного индекса.
Есть таблица перехода по ссылкам. 3 поля: айдишник по инкременту, домен, время.
На сегодняшний день число переходов приближается к миллиону.
Запрос на число переходов по доменам:
_____________
Бесплатному сыру в дырки не заглядывают...
Есть таблица перехода по ссылкам. 3 поля: айдишник по инкременту, домен, время.
На сегодняшний день число переходов приближается к миллиону.
Запрос на число переходов по доменам:
SELECT domen, COUNT(id) AS cid FROM table GROUP BY domen ORDER BY cid DESCПри двух простых индексах (по айдишнику и по домену) время выполнения запроса 17-18 секунд. При составном индексе меньше 0.5 секунды.
_____________
Бесплатному сыру в дырки не заглядывают...
Здесь расположена полная версия этой страницы.