mysql在不同的服务器上解释不同的结果，相同的查询，相同的数据库答案

【问题标题】：mysql explain different results on different servers, same query, same dbmysql在不同的服务器上解释不同的结果，相同的查询，相同的数据库
【发布时间】：2010-10-10 02:59:39
【问题描述】：

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

它在开发和测试中运行良好，但现在测试速度已大大放缓。在开发中花费 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，所有表都恢复正常。

【问题讨论】：

如果一个是Windows，另一个是Linux，它们几乎不一样......

标签： mysql join sql-execution-plan

【解决方案1】：

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

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

【讨论】：

我进行了分析，一切正常。无论如何运行优化，一切都很好。
我遇到了类似的问题。 2台服务器上的Mysql都带有debian 10。相同的数据库（第一台服务器上的mysqldump加载到第二台服务器上）。同一个查询的解释不同，一个查询的执行速度慢了 100 倍。 Otimize 在表格上运行良好并纠正了问题。 Mysql 有时会让我....

【解决方案2】：

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

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

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

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

【讨论】：

你让我吃惊！我很好奇为什么一个数据库不会使用索引而另一个会（或者为什么它最初使用但现在不再使用）。有什么想法吗？
优化器使用的统计数据可以收集在一个表中，但不能收集在另一个表中。

【解决方案3】：

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

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

【讨论】：

当您说“重建索引”时，您的意思是实际删除并重新创建吗？还是别的什么？
我想如果你只是做一个'REPAIR TABLE tbl_name QUICK;'这应该重建表上的所有索引。

【解决方案4】：

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

WHERE 子句针对不同的表（开发中的艺术家，测试中的节目）
它在流派中命中的行数不同（开发中为 2，测试中为 531281）。
第一个和第二个解释之间的其他杂项差异（主要是 EXTRA 中的内容）。

【讨论】：

是的，它们是同一个查询。我直接从测试中复制（速度很慢）并将其粘贴到 dev 中（速度很快）。

【解决方案5】：

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

谢谢！

【讨论】：