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

Question

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

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

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

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

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

Я запустил mysqlcheck, и все столы вернулись.

Answer 1

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

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

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

Между тем, сбор статистических данных для таблиц.

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Спасибо!

Answer 6

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

Единственное, что я нашел между этим сервером, это то, что версия подчиненного устройства немного выше, чем у ведущего.

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

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