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

Question

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

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

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

-+---------+------------------------------+------+------------------------------
---+
| 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)

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

У меня есть похожая проблема на моем главном и подчиненном серверах. Объясните план отличается между этими серверами. Основная проблема, я принудительно устанавливаю индекс на главном сервере в соответствии с ведомым устройством, даже если индекс не используется, даже после его принудительного применения.

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

Я проанализировал таблицу на нескольких таблицах, и все получилось. Я не мог понять, почему mysql не использует индекс, даже после его принудительного ввода.

Любая помощь будет высоко ценится.

Answer 5

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

Спасибо!

Answer 6

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

1. Предложение WHERE затрагивает разные таблицы (исполнители на dev, показывает на тестировании)
2. Количество строк, попадающих в жанры, различно (2 на dev, 531281 на тестирование).
3. Объясняются другие различия между первым и вторым (в основном это ДОПОЛНИТЕЛЬНО).