|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Доброе время суток.
Ребят, помогите создать индекс к запросу. Вот уже целый день мучаюсь и никак не получается. Перепробовал кучу вариантов. Все время присутствует "filesort".
Запрос
Неактивен
Сейчас вообще не используется индекс, согласно EXPLAIN. Возможно, слишком мало записей в таблице - добавьте записей до реалистичного количества.
Неактивен
Добавил полтары тысячи записей
Запрос
Неактивен
В первом результате отображается 1057 записей, значит это еще не расширенная таблица.
Неактивен
Извиняюсь, не совсем понял, что значит расширенная таблица?
2 запроса, написанных в предыдущем посте, были сделаны с уже заполненной таблицей.
Неактивен
Он пишет Type=ALL и rows=1057, значит в таблице всего 1057 строк.
Неактивен
Так, еще разок все перепроверил. В таблице 1824 записи.
Индекс, который более мение подходит для меня "без DESC после `date`" - KEY `ix_list` (`whom`,`visit`,`date`)
Explain запроса, для которого я подбираю индекс
Отредактированно pomuk123 (02.05.2012 14:01:03)
Неактивен
1824 записи - это тоже немного. Лучше сделать хотя бы 10 тысяч. Еще подозрительно, что rows=873, то есть приходится перебирать 873 строки. Наверное таблица наполнена не совсем реалистично - многие данные повторяются.
Вы пишете, что все супер, глядя на Extra, но длина используемого индекса в обоих случаях 8 байт, то есть используется одна и та же часть (`whom`,`visit`). Попробуйте с таким двойным индексом, будет ли такой же ответ. Когда в индексе было поле action, то длина используемого индекса была 10 байт. Попробуйте на большой таблице сделать профилирование запросов http://webew.ru/articles/2732.webew
Неактивен
Спасибо за ответ. Пошел изучать данную статью.
Неактивен
В общем.
1. Индекс по двум полям перестал работать и для запроса без "DESC".
2. Написал пхп-скрипик, который засунул мне 1.1 миллиона записей в таблицу. Записи были максимально рандомизированны, чтобы приблизть таблицу к реальной.
Ничего не изманилось. Также присутсвует "филесорт".
Самая "жрущая" опция из профилирования, где "филесорт"
| Sorting result | 7.637742 |
А там , где нету "DESC" и индекс сработал на ура -
| Sorting result | 0.000011 |
В общем, вывод - нужно правильно составить индекс.
Неактивен
Странно все это - в MySQL индексы двунаправленные, им все равно по возрастанию или убыванию сортировать. Но если есть практическая разница, значит какая-то асимметрия в реализации или бага.
Неактивен
А если убрать двойную сортиртовку, т.е вместо "ORDER BY visit, date DESC", написать "ORDER BY date DESC,а ключ сделать ix_list(`whom`, `date) - то тогда индекс сробатывает и нету филесорт, независимо от вида сортировки.
Отредактированно pomuk123 (03.05.2012 10:32:27)
Неактивен
Не двунаправленные индексы, к сожалению. Ну то есть будет работать
ORDER BY visit DESC, date DESC, но не в разных направлениях, увы.
Обычно в этом месте применяют какие-то костыли. Например, можно
хранить [-visit] вместо [visit], и тогда сортировка будет правильной.
Неактивен
Но хотя бы для первой колонки индекс будет использоваться?
Неактивен
LazY написал:
Но хотя бы для первой колонки индекс будет использоваться?
Для этого нужно знать какой путь выбирает MySQL - сортировка всего файлсортом или сортировка частично отсортированных данных кусочками (что не всегда даст выйгрыш, но теоретически может дать). Скорее всего первое, так как это не требует реализации дополнительного алгоритма. Наверное, это можно проверить в версии 5.6, используя Optimizer tracing, http://forge.mysql.com/wiki/MySQL_Inter … er_tracing
Неактивен
Посмотрите в сторону MariaDB
http://kb.askmonty.org/en/alter-table
index_col_name:
col_name [(length)] [ASC | DESC]
В ней возможно создать KEY(`whom` ASC, `visit` ASC, `date` DESC).
Неактивен
у нас проект на Mysql, поэтому нету возможности перейти на другую базу данных.
Вобщем решил проблему методом костыля, как советовали в предыдущих постах
Неактивен
MariaDB совместима c MySQL. То есть, если замените MySQL на MariaDB ничего менять в приложении не нужно (даже клиентские библиотеки).
Неактивен
Страниц: 1
