mysql объясняет разные результаты на разных серверах, один и тот же запрос, одну и ту же базу данных

После долгой работы я, наконец, получил довольно сложный запрос, который работал очень гладко и очень быстро возвращал результаты.

Он хорошо работал как при разработке, так и при тестировании, но теперь тестирование значительно замедлилось. Запрос объяснения, который занимает 0,06 секунды на dev и примерно столько же при тестировании, теперь составляет 7 секунд при тестировании.

Объяснения немного отличаются, и я не уверен, почему это объяснение от разработчика.

-+---------+------------------------------+------+------------------------------
---+
| id | select_type | table      | type   | possible_keys           | key
 | key_len | ref                          | rows | Extra
   |
+----+-------------+------------+--------+-------------------------+------------
-+---------+------------------------------+------+------------------------------
---+
|  1 | PRIMARY     |  | ALL    | NULL                    | NULL
 | NULL    | NULL                         |    5 |
   |
|  1 | PRIMARY     | tickets    | ref    | biddate_idx             | biddate_idx
 | 7       | showsdate.bid,showsdate.date |   78 |
   |
|  2 | DERIVED     | shows      | ALL    | biddate_idx,latlong_idx | NULL
 | NULL    | NULL                         | 3089 | Using temporary; Using fileso
rt |
|  2 | DERIVED     | genres     | ref    | bandid_idx              | bandid_idx
 | 4       | activehw.shows.bid           |    2 | Using index
   |
|  2 | DERIVED     | artists    | eq_ref | bid_idx                 | bid_idx
 | 4       | activehw.genres.bid          |    1 | Using where
   |
+----+-------------+------------+--------+-------------------------+------------

и в тестировании

| id | select_type | table      | type   | possible_keys           | key         | key_len | ref                          | rows   | Extra                                        |
+----+-------------+------------+--------+-------------------------+-------------+---------+------------------------------+--------+----------------------------------------------+
|  1 | PRIMARY     |  | ALL    | NULL                    | NULL        |    NULL | NULL                         |      5 |                                              |
|  1 | PRIMARY     | tickets    | ref    | biddate_idx             | biddate_idx |       7 | showsdate.bid,showsdate.date |     78 |                                              |
|  2 | DERIVED     | genres     | index  | bandid_idx              | bandid_idx  |     139 | NULL                         | 531281 | Using index; Using temporary; Using filesort |
|  2 | DERIVED     | artists    | eq_ref | bid_idx                 | bid_idx     |       4 | activeHW.genres.bid          |      1 |                                              |
|  2 | DERIVED     | shows      | eq_ref | biddate_idx,latlong_idx | biddate_idx |       7 | activeHW.artists.bid         |      1 | Using where                                  |
+----+-------------+------------+--------+-------------------------+-------------+---------+------------------------------+--------+----------------------------------------------+
5 rows in set (6.99 sec)

Порядок таблиц разный, хотя запросы точно такие же. Это и будет причиной замедления? если да, то как мне это исправить? Разработчик - windows, тестирование - centOs. оба работают с одной и той же версией mysql 5.0, и, как я уже сказал, тестирование прошло отлично, и я не внес никаких структурных изменений в базу данных.

Я запустил mysqlcheck, и все таблицы вернулись в порядке.


mysql join sql-execution-plan
person pedalpete    schedule 26.02.2009    source источник
comment
Если один Windows, а другой Linux, то вряд ли это одно и то же...   -  person Ryan Graham    schedule 26.02.2009

Ответы (5)


arrow_upward
3
arrow_downward

Первый план не использует индекс для shows.

Если вы уверены, что этот индекс вам поможет, форсируйте его:

SELECT ...
FROM ..., shows FORCE INDEX (biddate_idx) , ...
WHERE ...

А пока собирайте статистику для своих столов.

person Quassnoi    schedule 26.02.2009
comment
ты меня удивляешь! мне любопытно, почему один db не будет использовать индекс, а другой (или почему он использовал изначально, но не больше). Любые идеи? - person pedalpete; 26.02.2009
comment
Оптимизатор использует статистику, которая может быть собрана в одной таблице, но не собрана в другой. - person Quassnoi; 26.02.2009

arrow_upward
7
arrow_downward

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

Если данные одинаковы в обеих базах данных, я бы предложил использовать ANALYZE или OPTIMIZE для всех таблиц в вашем запросе.

person Greg    schedule 26.02.2009
comment
я провел анализ, и все пришло в норму. все равно запускал оптимизацию и все было нормально. - person pedalpete; 26.02.2009
comment
У меня была аналогичная проблема. Mysql на 2 серверах, оба с Debian 10. Одна и та же база данных (mysqldump на первом сервере загружается на второй сервер). Объяснение одного и того же запроса было другим, и выполнение одного из них было в 100 раз медленнее. Оптимизация для таблиц работала нормально и устранила проблему. Mysql иногда заставляет меня.... - person Donapieppo; 03.12.2020

arrow_upward
3
arrow_downward

Я бы попробовал восстановить статистику и перестроить индексы для всех таблиц и посмотреть, решит ли это вашу проблему - вероятно, поэтому планы будут другими.

Это может быть много других вещей (память, диск, различия ОС, другие нагрузки и т. д.), но я предполагаю, что это, вероятно, не проблема, поскольку вы упомянули, что раньше все работало нормально.

person Eric Petroelje    schedule 26.02.2009
comment
когда вы говорите «перестроить индексы», вы имеете в виду удаление и воссоздание? или что-то другое? - person pedalpete; 26.02.2009
comment
Я думаю, что если вы просто сделаете 'REPAIR TABLE tbl_name QUICK;' это должно перестроить все индексы в таблице. - person Eric Petroelje; 26.02.2009

arrow_upward
0
arrow_downward

Вы уверены, что это из одного и того же запроса? Объяснения не просто немного отличаются, между ними есть значительные различия:

  1. Предложение WHERE попадает в разные таблицы (исполнители в разработке, показы на тестировании)
  2. Количество строк в жанрах разное (2 для разработчиков, 531281 для тестирования).
  3. Другие разные различия между первым и вторым объясняются (в основном, в EXTRA).
person Powerlord    schedule 26.02.2009
comment
да, это один и тот же запрос. Я скопировал его прямо из тестирования (что было медленно) и вставил в dev (что было быстро). - person pedalpete; 26.02.2009

arrow_upward
0
arrow_downward

Мы только что столкнулись с очень похожей проблемой: недавно созданному мастеру потребовалось несколько минут для выполнения того же запроса, который старый мастер (с меньшей мощностью) выполнил за доли секунды. Мы быстро запустили таблицу восстановления для двух таблиц myisam в запросе, и теперь новый мастер выполняет запрос как минимум так же быстро, как и старый.

Спасибо!

person Community    schedule 29.05.2009