Mysql запросы сканируют при переключении серверов

Question

На прошлой неделе я столкнулся с проблемой, переходя от dev-тестирования, когда один из моих запросов, который отлично работал в dev, сканировал мой тестовый сервер.

Это было исправлено добавлением FORCE INDEX к одному из индексов в запросе.

Теперь я загрузил ту же базу данных на рабочий сервер (и она работает с командой FORCE INDEX, и она снова замедлилась.

Есть идеи, что может вызвать что-то подобное? Тестирование и prod работают под управлением одной и той же ОС и версии mysql (в отличие от dev).

Вот запрос и объяснение из него.

 EXPLAIN SELECT showsdate.bid, showsdate.bandid, showsdate.date, showsdate.time,
    -> showsdate.title, showsdate.name, showsdate.address, showsdate.rank, showsdate.city, showsdate.state,
    ->  showsdate.lat, showsdate.`long` , tickets.link, tickets.lowprice, tickets.highprice, tickets.source
    -> , tickets.ext, artistGenre, showsdate.img
    -> FROM tickets
    -> RIGHT OUTER JOIN (
    -> SELECT shows.bid, shows.date, shows.time, shows.title, artists.name, artists.img, artists.rank, artists
    -> .bandid, shows.address, shows.city, shows.state, shows.lat, shows.`long`, GROUP_CONCAT(genres.genre SEPARATOR
    ->  ' | ') AS artistGenre
    -> FROM shows FORCE INDEX (biddate_idx)
    -> JOIN artists ON shows.bid = artists.bid JOIN genres ON artists.bid=genres.bid
    -> WHERE  `long` BETWEEN -74.34926984058 AND -73.62463215942 AND lat BETWEEN 40.39373515942 AND 41.11837284058
    ->  AND shows.date >= '2009-03-02'  GROUP BY shows.bid, shows.date ORDER BY  shows.date, artists.rank  DESC
    ->  LIMIT 0, 30
    -> )showsdate ON showsdate.bid = tickets.bid AND showsdate.date = tickets.date;
+----+-------------+------------+--------+---------------+-------------+---------+------------------------------+--------+----------------------------------------------+
| id | select_type | table      | type   | possible_keys | key         | key_len | ref                          | rows   | Extra                                        |
+----+-------------+------------+--------+---------------+-------------+---------+------------------------------+--------+----------------------------------------------+
|  1 | PRIMARY     | <derived2> | ALL    | NULL          | NULL        | NULL    | NULL                         |     30 |                                              |
|  1 | PRIMARY     | tickets    | ref    | biddate_idx   | biddate_idx | 7       | showsdate.bid,showsdate.date |      1 |                                              |
|  2 | DERIVED     | genres     | index  | bandid_idx    | bandid_idx  | 141     | NULL                         | 531281 | Using index; Using temporary; Using filesort |
|  2 | DERIVED     | shows      | ref    | biddate_idx   | biddate_idx | 4       | activeHW.genres.bid          |      5 | Using where                                  |
|  2 | DERIVED     | artists    | eq_ref | bid_idx       | bid_idx     | 4       | activeHW.genres.bid          |      1 |                                              |
+----+-------------+------------+--------+---------------+-------------+---------+------------------------------+--------+----------------------------------------------+

Answer 1

Я думаю, что вмешался, когда вы задали этот вопрос о различиях в dev -> test.

Вы пытались пересоздать индексы и пересчитать статистику? Как правило, форсировать индекс - плохая идея, так как оптимизатор обычно делает правильный выбор относительно того, какие индексы использовать. Однако это предполагает, что он имеет хорошую статистику для работы и что индексы не сильно фрагментированы.

ETA:

Чтобы перестроить индексы, используйте:

REPAIR TABLE tbl_name QUICK;

Для пересчета статистики:

ANALYZE TABLE tbl_name;

Answer 2

Два сервера настроены одинаково? Похоже, что вы можете пересечь «переломный момент» в производительности MySQL. Я бы сравнил конфигурации MySQL; там может быть другой параметр памяти.

Answer 3

Есть ли на тестовом сервере только 10 записей, а на рабочем сервере 1000000000 записей? Это также может привести к разному времени выполнения