8

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

它在开发和测试中运行良好，但现在测试速度大大放缓。在开发中花费 0.06 秒并且在测试中大致相同的解释查询现在在测试中是 7 秒。

解释略有不同，我不确定为什么会这样 来自开发的解释

-+---------+------------------+------+ ------------------------------
---+
| 编号 | 选择类型 | 表| 类型 | 可能的键 | 钥匙
 | key_len | 参考 | 行 | 额外的
   |
+----+-------------+------------+--------+-------- -----------------+------------
-+---------+------------------+------+ ------------------------------
---+
| 1 | 初级 | | 全部 | 空 | 空值
 | 空 | 空 | 5 |
   |
| 1 | 初级 | 门票 | 参考 | 投标日期_idx | 出价日期_idx
 | 7 | 演出日期.出价,演出日期.日期 | 78 |
   |
| 2 | 派生 | 节目 | 全部 | biddate_idx,latlong_idx | 空值
 | 空 | 空 | 3089 | 使用临时的；使用文件
rt |
| 2 | 派生 | 流派 | 参考 | bandid_idx | bandid_idx
 | 4 | activehw.shows.bid | 2 | 使用索引
   |
| 2 | 派生 | 艺术家 | eq_ref | 出价IDX | bid_idx
 | 4 | activehw.genres.bid | 1 | 使用哪里
   |
+----+-------------+------------+--------+-------- -----------------+------------

并且在测试中

| 编号 | 选择类型 | 表| 类型 | 可能的键 | 关键 | key_len | 参考 | 行 | 额外 |
+----+-------------+------------+--------+-------- -----------------+--------------+---------+-------- ----------------------+--------+------------------ --------------------------------------------+
| 1 | 初级 | | 全部 | 空 | 空 | 空 | 空 | 5 | |
| 1 | 初级 | 门票 | 参考 | 投标日期_idx | 投标日期_idx | 7 | 演出日期.出价,演出日期.日期 | 78 | |
| 2 | 派生 | 流派 | 索引 | bandid_idx | bandid_idx | 139 | 空 | 531281 | 使用索引；使用临时的；使用文件排序 |
| 2 | 派生 | 艺术家 | eq_ref | 出价IDX | 出价IDX | 4 | activeHW.genres.bid | 1 | |
| 2 | 派生 | 节目 | eq_ref | biddate_idx,latlong_idx | 投标日期_idx | 7 | activeHW.artists.bid | 1 | 使用位置 |
+----+-------------+------------+--------+-------- -----------------+--------------+---------+-------- ----------------------+--------+------------------ --------------------------------------------+
5 行一组（6.99 秒）

即使查询完全相同，表的顺序也不同。这是导致减速的原因吗？如果是这样，我将如何解决它？开发是windows，测试是centOs。两者都运行相同版本的 mysql 5.0，就像我说的，测试运行完美，我没有对数据库进行任何结构更改。

我运行了 mysqlcheck，所有表都恢复正常。

4

5 回答 5

7

MySQL 查看表中的数据以及查询本身来决定使用哪个执行计划。

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

于 2009-02-26T16:15:01.473 回答
5

第一个计划不使用 index on shows。

如果您确定此索引会对您有所帮助，请强制执行：

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

同时，为您的表格收集统计信息。

于 2009-02-26T16:17:49.097 回答
3

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

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

于 2009-02-26T16:13:45.500 回答
0

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

  1. WHERE 子句针对不同的表（开发中的艺术家，测试中的显示）
  2. 它在流派中命中的行数不同（开发时为 2，测试时为 531281）。
  3. 第一个和第二个解释之间的其他杂项差异（主要是额外的东西）。
于 2009-02-26T16:21:55.030 回答
0

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

谢谢！

于 2009-05-29T08:35:27.083 回答