サーバーを切り替えるときにMysqlがクロールする

Question

先週devで完全に実行されたクエリの1つがテストサーバーでクロールされていた開発テストから問題が発生しました。

これは、クエリのインデックスの1つにFORCE INDEXを追加することで修正されました。

は今、私は本番サーバーに同じデータベースをロードした（そしてそれは、FORCE INDEXコマンドで実行している、それが再び鈍化している。

このような何かが起こることを引き起こすものを任意のアイデアを？テストとPRODは両方

が

ここでクエリです。（DEVとは違って）同じOSとMySQLのバージョンを実行しているし、そこから説明します。

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 - >テストの場合

インデックスを再構築して統計を再計算しましたか？一般に、オプティマイザは通常、どのインデックスを使用するかに関して良い選択をするので、インデックスを強制するのは悪い考えです。しかし、それは、それが働く良い統計量を持っていることと、インデックスが深刻に断片化されていないことを前提としています。

ETA：

は、インデックスを再構築するには、使用：

REPAIR TABLE tbl_name QUICK; 

は、統計を再計算する：

ANALYZE TABLE tbl_name; 

Answer 2

テストサーバーのみ10レコードと本番サーバ1000000000のレコードを持っていますか？ これにより、実行時間が異なる可能性があります。

Answer 3

2台のサーバーが同じ構成になっていますか？あなたがMySQLのパフォーマンスにおいて「転換点」を超えているように思えます。私はMySQLの設定を比較したいと思います。異なるメモリパラメータの方法があるかもしれません。