Question

经过大量工作后，我终于得到了一个相当复杂的查询，可以非常流畅地工作并且很快返回结果。

它在开发和测试方面运行良好，但现在测试速度已大大减慢。解释查询在开发时需要0.06秒，在测试中大致相同，现在测试时间为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)

表的顺序不同，即使查询完全相同。这会导致经济放缓吗？如果是的话，我该如何解决？开发是windows，测试是centOs。两个都运行相同版本的mysql 5.0，就像我说的，测试运行完美，我没有对数据库进行任何结构更改。

我运行了mysqlcheck，所有表都回来了。

Answer 1

MySQL会查看表中的数据以及查询本身，以确定要使用的执行计划。

如果两个数据库中的数据相同，我建议在查询中的所有表上使用ANALYZE或OPTIMIZE。

Answer 2

我会尝试重新生成统计信息并重建所有表的索引，看看是否能解决问题 - 这可能就是为什么计划会有所不同。

它还有很多其他的东西（内存，磁盘，操作系统差异，其他负载等），但我认为那些可能不是问题，因为你之前提到它运行正常。

Answer 3

第一个计划不使用shows上的索引。

如果您确定此索引可以帮助您，请强制它：

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

同时，收集表格的统计数据。

Answer 4

我的主服务器和从服务器上也有类似的问题。这些服务器之间的解释计划不同。主要问题是，我根据slave强制主服务器上的索引，即使这样，即使在强制它之后索引也没有被使用。

我在这些服务器之间找到的唯一不同之处是奴隶版本略高于主版本。

我在几张桌子上分析了表格，结果很好。我无法理解为什么即使在我强行使用它之后mysql也没有使用索引。

非常感谢任何帮助。

Answer 5

您确定这些来自同一个查询吗？解释不仅略有不同，它们之间存在很大差异：

WHERE子句遇到不同的表（dev上的艺术家，测试时显示）
它在流派中击中的行数不同（开发时为2，测试时为531281）。
第一个和第二个之间的其他杂项差异（主要是EXTRA中的内容）。

Answer 6

我们刚刚遇到了一个非常类似的问题，一个新建的主人花了几分钟执行相同的查询，以便在几分之一秒内完成旧主人（功率较小）。我们在查询中的两个myisam表上快速运行修复表，现在新主服务器执行查询至少与旧查询一样快。

谢谢！

mysql解释不同服务器上的不同结果，同一查询，同一个数据库

6 个答案: