Question

我上周遇到了一个问题，从开发测试开始，我的一个查询在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的差异的问题时，我想我已经插话了 - >测试。

您是否尝试过重建索引并重新计算统计信息？通常，强制索引是一个坏主意，因为优化器通常会选择使用哪些索引。但是，这假设它具有良好的统计数据，并且索引不会严重分散。

ETA：

要重建索引，请使用：

REPAIR TABLE tbl_name QUICK;

重新计算统计数据：

ANALYZE TABLE tbl_name;

Answer 2

测试服务器只有10条记录和生产服务器1000000000条记录吗？这也可能导致不同的执行时间

Answer 3

两台服务器的配置是否相同？听起来你可能正在跨越MySQL性能的“转折点”。我会比较MySQL的配置;可能存在不同的内存参数。

切换服务器时，Mysql查询爬网

3 个答案: