
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
22.01.2015, 06:14:58
|
|||
|---|---|---|---|
Почему using temporary когда маленький cardinality |
|||
|
#18+
Преамбула. 2 БД с двумя идентичными - favorite, и двумя одинаковыми таблицами - catalog. Делается запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. БД1 отвечает за микросекунды, БД2 думает 5 секунд. Explain показывает что БД2 не использует индекс, включает using temporary. Амбула. В свойствах индексов найдено отличие: в таблице favorite БД1 cardinality=1, в идентичной таблице БД2 = 10. Ну потому что в БД2 просто 1 запись, а в БД2 - 10 штук. Через веб-интерфейс сайта добавил дюжину записей в избранное БД2 - using temporary сняло как рукой. Причем не важно какой там номер юзера, хоть 0 - как в запросе. БД2 стала отвечать за микросекунды. Дамп структуры избранного: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Дамп каталога (общая часть двух таблиц, специфика вырезана) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Вопрос: это значит если юзеры удалят все избранное, или пока они туда не понакидают - БД будет зверски тормозить? Или как сделать чтобы и с пустой таблицей избранного запрос не качал из временной таблицы? Заранее спасибо за полезные советы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2015, 10:10:28
|
|||
|---|---|---|---|
Почему using temporary когда маленький cardinality |
|||
|
#18+
Можно попытаться принудить MySQL всегда использовать индекс. См. Index Hint Syntax . Я как-то налетал на схожую ситуацию, когда добавление индекса на крошечной таблице (меньше десятка записей) на порядок ускоряло запрос. Природу этого ускорения я тогда не выяснял, но есть ощущение, что это связано с тем, что в MyISAM нормально кэшируются только индексы, а содержимое таблицы - нет. P.S.debloggerАмбула.Фабула. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2015, 17:22:01
|
|||
|---|---|---|---|
Почему using temporary когда маленький cardinality |
|||
|
#18+
miksoft, Да, когда написал припомнил что вроде есть форсированный режим, но искать не стал. Сейчас поищу, спасибо за совет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2015, 17:28:07
|
|||
|---|---|---|---|
Почему using temporary когда маленький cardinality |
|||
|
#18+
upd, теперь видать надо выкашивать индексы отдельно - удаление записей из избранного ситуацию не ухудшило чтобы проверить ваш совет. Отпишусь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2015, 17:33:48
|
|||
|---|---|---|---|
Почему using temporary когда маленький cardinality |
|||
|
#18+
Попутный совет - после таких операций как создание/удаление индекса и вставка большого количества записей делайте OPTIMIZE TABLE, а после удаления существенного количества записей делайте ANALYZE TABLE этой таблице. Иногда может изменить картину. Обычно в лучшую сторону. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2015, 18:09:59
|
|||
|---|---|---|---|
Почему using temporary когда маленький cardinality |
|||
|
#18+
Удалил индекс, создал заново, запрос исправно начал лагать по 3 секунды. Попытки применить use index только потратили время. Заенфорсил force и стало все сладко да гладко. Вот так теперь выглядит. Код: sql 1. 2. 3. 4. 5. Про оптимизацию PMA подсказывает когда заглядываешь в нем в структуры время от времени. Но в этот раз я сперва сам все проверил, анализировал и оптимизировал. PS А нормально так кушает этот SQL_CALC_FOUND_ROWS. Субъективно на фоне работы скрипта не заметно, а по числам - без него и лимита: Showing rows 0 - 29 ( 14,057 total, Query took 0.0045 sec) - с подсчетом и лимитом Showing rows 0 - 35 ( 36 total, Query took 0.2184 sec) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2015, 18:13:28
|
|||
|---|---|---|---|
Почему using temporary когда маленький cardinality |
|||
|
#18+
debloggerPS А нормально так кушает этот SQL_CALC_FOUND_ROWS.Естественно. При его использовании не срабатывает оптимизация ORDER BY + LIMIT и MySQL сортирует весь объем записей, а не только 36 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=47&mobile=1&tid=1833670]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
49ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 331ms |

| 0 / 0 |
