|
|
|
Почему 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, 06:14:58 |
|
||
|
Почему using temporary когда маленький cardinality
|
|||
|---|---|---|---|
|
#18+
Можно попытаться принудить MySQL всегда использовать индекс. См. Index Hint Syntax . Я как-то налетал на схожую ситуацию, когда добавление индекса на крошечной таблице (меньше десятка записей) на порядок ускоряло запрос. Природу этого ускорения я тогда не выяснял, но есть ощущение, что это связано с тем, что в MyISAM нормально кэшируются только индексы, а содержимое таблицы - нет. P.S.debloggerАмбула.Фабула. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2015, 10:10:28 |
|
||
|
Почему using temporary когда маленький cardinality
|
|||
|---|---|---|---|
|
#18+
miksoft, Да, когда написал припомнил что вроде есть форсированный режим, но искать не стал. Сейчас поищу, спасибо за совет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2015, 17:22:01 |
|
||
|
Почему using temporary когда маленький cardinality
|
|||
|---|---|---|---|
|
#18+
upd, теперь видать надо выкашивать индексы отдельно - удаление записей из избранного ситуацию не ухудшило чтобы проверить ваш совет. Отпишусь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2015, 17:28:07 |
|
||
|
Почему using temporary когда маленький cardinality
|
|||
|---|---|---|---|
|
#18+
Попутный совет - после таких операций как создание/удаление индекса и вставка большого количества записей делайте OPTIMIZE TABLE, а после удаления существенного количества записей делайте ANALYZE TABLE этой таблице. Иногда может изменить картину. Обычно в лучшую сторону. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2015, 17:33:48 |
|
||
|
Почему 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:09:59 |
|
||
|
Почему using temporary когда маленький cardinality
|
|||
|---|---|---|---|
|
#18+
debloggerPS А нормально так кушает этот SQL_CALC_FOUND_ROWS.Естественно. При его использовании не срабатывает оптимизация ORDER BY + LIMIT и MySQL сортирует весь объем записей, а не только 36 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2015, 18:13:28 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38861002&tid=1833670]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 382ms |

| 0 / 0 |
