|
Разные планы запросов на разных серверах
|
|||
---|---|---|---|
#18+
Добрый день! Есть несколько серверов (linux) с развернутыми на них MySQL (innodb_version=5.7.21). Конфигурации идентичны, тк разворачивались с помощью docker. База везде одинаковая, наполнение по количеству записей - разное. В каких то, записей существенно больше, в каких то совсем чуть чуть. Недавно заметили что на одной (средняя по объему) из инстанций начал очень тормозить запрос. При этом такой же запрос на других инстанциях, даже с большим количеством записей, работает гораздо быстрее. План запроса, соответственно тоже различается. В поисках причин, выяснила, что не используется один из индексов (индекс по полю типа datetime), для поля которое участвует в фильтре. Если удалить индекс, все начинает работать быстро. Индекс пересоздали. Даже базу восстанавливали. Ничего не помогает. При этом на всех других инстанциях этот индекс есть и он используется. И на них как раз ситуация обратная, без этого индекса все начинает тормозить. Как так может быть? Конфигурация базы одинаковая везде. Сервера +- тоже одинаковые. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2020, 15:09 |
|
Разные планы запросов на разных серверах
|
|||
---|---|---|---|
#18+
План выполнения, который строит сервер, зависит от накопленной статистики таблицы. Которая в свою очередь зависит от данных, и немного от истории (ошибки обновления статистики - они накапливаются). Для обновления статистики есть ANALYZE TABLE. Эффективность использования индекса зависит от реальной статистики. На одной и той же структуре при разном наполнении индекс может быть эффективен, а может и наоборот, тормозить процесс, и его лучше не использовать. В общем, то, что Вы наблюдаете - совершенно нормальная ситуация. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2020, 16:14 |
|
Разные планы запросов на разных серверах
|
|||
---|---|---|---|
#18+
Akina, Спасибо за ответ! ANALYZE TABLE делали. Не помогло. Разворачивала себе дамп этой базы, и так же ситуация, без индекса работает нормально, с ним - жуткие тормоза. Так что дело точно не в железе. С другой стороны, у нас много аналогичных баз, и там все хорошо работает с индексом. Хочется найти причину почему именно эта база так себя ведет. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2020, 13:59 |
|
Разные планы запросов на разных серверах
|
|||
---|---|---|---|
#18+
Такова статистика данных. Оптимизатор выбирает использование индекса, считая его селективность высокой, однако для указанных данных и/или условий отбора она низкая, поэтому затраты на выполнение с использованием индекса выше, чем в случае прямого сканирования. Или имеется какое-то неудачное для конкретного набора данных сочетание факторов на следующих стадиях - скажем, неожиданно большая субвыборка приводит к медленному слиянию. В общем, проблема именно в конкретной статистике - иной причины скорее всего нет. Я лично сталкивался с ситуацией, когда пришлось писать два запроса - в одном индекс форсился, во втором игнорился. Первый выполнялся, если время было от полуночи до 8 утра, второй в остальное время. Вот так менялась статистика обрабатываемых данных... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2020, 15:34 |
|
|
start [/forum/search_topic.php?author=Untrace&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
131ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
others: | 797ms |
total: | 1035ms |
0 / 0 |