当前位置:  开发笔记 > 后端 > 正文

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

如何解决《mysql解释不同服务器上的不同结果,同一查询,同一个数据库》经验,为你挑选了1个好方法。

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

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



1> Greg..:

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

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

推荐阅读
云聪京初瑞子_617
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有