MySQL Master и Slave с совершенно разными планами выполнения

У меня есть сложный запрос MySQL, который объединяет три таблицы и сам присоединяется к одной таблице.

Есть Master и Slave, которые имеют идентичные данные и индексы. Мастер — это мощный блок по сравнению с ведомым, но запрос выполняется в 10 раз быстрее на ведомом (в период легкой нагрузки на ведущего).

Планы выполнения сильно отличаются.

Master execution plan
1, 'SIMPLE', 'table3_', 'const', 'PRIMARY', 'PRIMARY', '12', 'const', 1, 100.00, 'Using temporary; Using filesort'
1, 'SIMPLE', 'table2_', 'ref', 'PRIMARY,FK376E02E910238FCA', 'FK376E02E910238FCA', '13', 'const', 105, 100.00, 'Using where'
1, 'SIMPLE', 'table0_', 'ref', 'FK57012F937DD0DC02,FK57012F9398CD28D0', 'FK57012F9398CD28D0', '13', 'table2_.ID', 1515, 100.00, 'Using where'
1, 'SIMPLE', 'table1_', 'eq_ref', 'PRIMARY,FKE7E81F1ED170D4C9', 'PRIMARY', '8', 'table0_.FK_ID', 1, 100.00, 'Using where'

Slave execution plan
1, 'SIMPLE', 'table3_', 'const', 'PRIMARY', 'PRIMARY', '12', 'const', 1, 100.00, 'Using filesort'
1, 'SIMPLE', 'table1_', 'ref', 'PRIMARY,FKE7E81F1ED170D4C9', 'FKE7E81F1ED170D4C9', '9', 'const', 187398, 100.00, 'Using where'
1, 'SIMPLE', 'table0_', 'ref', 'FK57012F937DD0DC02,FK57012F9398CD28D0', 'FK57012F937DD0DC02', '9', 'table1_.ID', 1, 100.00, 'Using where'
1, 'SIMPLE', 'table2_', 'eq_ref', 'PRIMARY,FK376E02E910238FCA', 'PRIMARY', '12', 'table0_.FK_ID', 1, 100.00, 'Using where'

Таблицы обрабатываются в разном порядке, и главная БД использует как временную таблицу, так и сортировку по файлам, а подчиненная использует только сортировку по файлам.

Какие факторы могли привести к таким разным планам с таким разным временем выполнения?

ОБНОВИТЬ:

Возможно ли, что это связано со статистикой индекса? Я планирую запустить ANALYZE TABLE на Мастере в период небольшого объема. SHOW INDEX показывает очень разную кардинальность некоторых ключей между Master и Slave.


mysql sql-execution-plan
person Eric J.    schedule 15.12.2009    source источник
comment
Это нить той же проблемы объясните разные результаты на разных серверах, один и тот же запрос db"> stackoverflow.com/questions/591210/   -  person Sanghyun Lee    schedule 01.02.2013

Ответы (3)


arrow_upward
2
arrow_downward

MySQL оптимизирует запросы на основе собранной статистики.

Глядя на ваш вывод, вы видите, что они используют разные клавиши, возможно, вам придется добавить ключевые подсказки или даже принудительно нажимать клавиши.

ИЗ таблицы2_ ПРИСОЕДИНЯЙСЯ

должен стать

ОТ table2_ ИСПОЛЬЗУЙТЕ КЛЮЧ('FK376E02E910238FCA') ПРИСОЕДИНЯЙТЕСЬ

Или ПРИНУДИТЕЛЬНЫЙ КЛЮЧ

person MindStalker    schedule 15.12.2009
comment
Фактическая статистика будет меняться со временем, поэтому я не хотел бы давать ключевые подсказки. Я собираюсь попробовать ANALYZE TABLE сегодня вечером, чтобы восстановить статистику и посмотреть, поможет ли это. Если это так, я добавлю это в план текущего обслуживания БД. - person Eric J.; 15.12.2009
comment
После запуска ANALYZE TABLE на соответствующих таблицах в ведущем я получил тот же план выполнения и сравнимое время выполнения, что и на ведомом. Я собираюсь выбрать этот ответ, потому что он был ближе всего к собранной статистике, но я не указал ключ в запросе и не думаю, что в данном случае это хорошая идея. - person Eric J.; 16.12.2009

arrow_upward
0
arrow_downward

Для меня это выглядит как ошибка в оптимизаторе запросов. Я бы сообщил об этом.

На обоих серверах установлена ​​одна и та же версия MySQL?

person Ben S    schedule 15.12.2009
comment
Оба используют одну и ту же версию MySQL, хотя главный сервер использует 64-разрядную версию, а подчиненный — 32-разрядную. - person Eric J.; 15.12.2009
comment
просто другой план это не баг - person noonex; 15.12.2009
comment
Другой план, который приводит к более медленному выполнению на более быстром оборудовании. Это звучит как ошибка производительности для меня. - person Ben S; 16.12.2009
comment
Проблема заключалась в том, что статистика индекса на Мастере была не очень точной. Ведомый сервер имел довольно точную статистику, потому что он был подключен к ведущему сравнительно недавно и поэтому создал индексную статистику с гораздо большим объемом данных. - person Eric J.; 16.12.2009

arrow_upward
0
arrow_downward

SHOW INDEX показывает очень разную кардинальность некоторых ключей между Master и Slave.

Я столкнулся с той же проблемой и обнаружил, что причина в ней: разная кардинальность. А потом я запустил таблицу анализа, мощность осталась прежней, и проблема исчезла.

person ytll21    schedule 20.01.2021