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

ped*_*ete 6 mysql join sql-execution-plan

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

它在开发和测试方面运行良好,但现在测试速度已大大减慢.解释查询在开发上需要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,所有表都回来了.

Gre*_*reg 5

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

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


Qua*_*noi 5

第一个计划不使用索引shows

如果您确定该索引对您有帮助,请强制执行:

SELECT ...
FROM ..., shows FORCE INDEX (biddate_idx) , ...
WHERE ...
Run Code Online (Sandbox Code Playgroud)

同时,收集表的统计数据。