两台服务器上的mysql的数据和索引都是一样的，索引都删除重建了
一：同样的一条语句，在原MySQL上运行只要0.003s，而新的MySQL则需要16s，通过explain分析后，发现默认情况下，新MySql使用的索引策略与原来的不一样，请问有没办法使两者在默认情况下使用相同的策略？
二：我通过force index，强制使新MySQL使用原来的策略，速度明显加快了，但还是需要5s
三：这个是最奇怪的，我使用程序或SQLyog工具连接新MySQL进行查询，都要16s，但如果使用navicat去查询，只需要0.1s，而且他们的explain输出都是一模一样的
4 个解决方案
#1
一：同样的一条语句，在原MySQL上运行只要0.003s，而新的MySQL则需要16s，通过explain分析后，发现默认情况下，新MySql使用的索引策略与原来的不一样，请问有没办法使两者在默认情况下使用相同的策略？
执行以下analyze table
二：我通过force index，强制使新MySQL使用原来的策略，速度明显加快了，但还是需要5s
同上
三：这个是最奇怪的，我使用程序或SQLyog工具连接新MySQL进行查询，都要16s，但如果使用navicat去查询，只需要0.1s，而且他们的explain输出都是一模一样的
跟工具没关系
执行以下analyze table
二：我通过force index，强制使新MySQL使用原来的策略，速度明显加快了，但还是需要5s
同上
三：这个是最奇怪的，我使用程序或SQLyog工具连接新MySQL进行查询，都要16s，但如果使用navicat去查询，只需要0.1s，而且他们的explain输出都是一模一样的
跟工具没关系
#2
一、二点谢了
第三点，我刚才直接到新MySQL使用命令进行查询，发现查询速度和navicat的差不多一样，0.06s
也就是说直接服务器查询和navicat都非常快，但使用程序和SQLoy工具查询非常慢
#3
SHOW PROCESSLIST;出现Sending data
#4
找到原因的：
一 以select * from a 为例， navicat和服务器会直接执行，而SQLyog当超过1000行的时候会自动加上limit，程序使用了limit分页
二 以前那个是MySQL 5.1/5 新的用了MySQL5.6 MySQL5.6有对limit优化
既然高版本对limit进行了优化，为什么使用了limit的反而会更慢呢？通过EXPLAIN分析后发现，带limit和不带的执行计划发送了改变！！
SQL的条件用 Where A or B group by C order by C表示，A、B、C都有独立的索引，在5.5以前的MYSQL版本，limit和全部搜索都是使用A+B的联合索引；而在5.6版，全部搜索使用A+B的联合索引，加上limit后却用了C索引，导致速度变慢！
由于C索引在其他查询需要用到，不可能删除，暂时没找到很好的解决办法，最后用了一个比较曲折的方式：
基于实际情况，group by 后，C是唯一的，因此我在order by后面加上一个条件D（即Where A or B group by C order by C,D），这样做并不会对结果的顺序造成任何影响，同时不符合C索引的使用条件，进而使MySQL用回A+B的联合索引
期望有更好的答案，7天后再结帖
一 以select * from a 为例， navicat和服务器会直接执行，而SQLyog当超过1000行的时候会自动加上limit，程序使用了limit分页
二 以前那个是MySQL 5.1/5 新的用了MySQL5.6 MySQL5.6有对limit优化
既然高版本对limit进行了优化，为什么使用了limit的反而会更慢呢？通过EXPLAIN分析后发现，带limit和不带的执行计划发送了改变！！
SQL的条件用 Where A or B group by C order by C表示，A、B、C都有独立的索引，在5.5以前的MYSQL版本，limit和全部搜索都是使用A+B的联合索引；而在5.6版，全部搜索使用A+B的联合索引，加上limit后却用了C索引，导致速度变慢！
由于C索引在其他查询需要用到，不可能删除，暂时没找到很好的解决办法，最后用了一个比较曲折的方式：
基于实际情况，group by 后，C是唯一的，因此我在order by后面加上一个条件D（即Where A or B group by C order by C,D），这样做并不会对结果的顺序造成任何影响，同时不符合C索引的使用条件，进而使MySQL用回A+B的联合索引
期望有更好的答案，7天后再结帖
#1
一：同样的一条语句，在原MySQL上运行只要0.003s，而新的MySQL则需要16s，通过explain分析后，发现默认情况下，新MySql使用的索引策略与原来的不一样，请问有没办法使两者在默认情况下使用相同的策略？
执行以下analyze table
二：我通过force index，强制使新MySQL使用原来的策略，速度明显加快了，但还是需要5s
同上
三：这个是最奇怪的，我使用程序或SQLyog工具连接新MySQL进行查询，都要16s，但如果使用navicat去查询，只需要0.1s，而且他们的explain输出都是一模一样的
跟工具没关系
执行以下analyze table
二：我通过force index，强制使新MySQL使用原来的策略，速度明显加快了，但还是需要5s
同上
三：这个是最奇怪的，我使用程序或SQLyog工具连接新MySQL进行查询，都要16s，但如果使用navicat去查询，只需要0.1s，而且他们的explain输出都是一模一样的
跟工具没关系
#2
一、二点谢了
第三点，我刚才直接到新MySQL使用命令进行查询，发现查询速度和navicat的差不多一样，0.06s
也就是说直接服务器查询和navicat都非常快，但使用程序和SQLoy工具查询非常慢
#3
SHOW PROCESSLIST;出现Sending data
#4
找到原因的：
一 以select * from a 为例， navicat和服务器会直接执行，而SQLyog当超过1000行的时候会自动加上limit，程序使用了limit分页
二 以前那个是MySQL 5.1/5 新的用了MySQL5.6 MySQL5.6有对limit优化
既然高版本对limit进行了优化，为什么使用了limit的反而会更慢呢？通过EXPLAIN分析后发现，带limit和不带的执行计划发送了改变！！
SQL的条件用 Where A or B group by C order by C表示，A、B、C都有独立的索引，在5.5以前的MYSQL版本，limit和全部搜索都是使用A+B的联合索引；而在5.6版，全部搜索使用A+B的联合索引，加上limit后却用了C索引，导致速度变慢！
由于C索引在其他查询需要用到，不可能删除，暂时没找到很好的解决办法，最后用了一个比较曲折的方式：
基于实际情况，group by 后，C是唯一的，因此我在order by后面加上一个条件D（即Where A or B group by C order by C,D），这样做并不会对结果的顺序造成任何影响，同时不符合C索引的使用条件，进而使MySQL用回A+B的联合索引
期望有更好的答案，7天后再结帖
一 以select * from a 为例， navicat和服务器会直接执行，而SQLyog当超过1000行的时候会自动加上limit，程序使用了limit分页
二 以前那个是MySQL 5.1/5 新的用了MySQL5.6 MySQL5.6有对limit优化
既然高版本对limit进行了优化，为什么使用了limit的反而会更慢呢？通过EXPLAIN分析后发现，带limit和不带的执行计划发送了改变！！
SQL的条件用 Where A or B group by C order by C表示，A、B、C都有独立的索引，在5.5以前的MYSQL版本，limit和全部搜索都是使用A+B的联合索引；而在5.6版，全部搜索使用A+B的联合索引，加上limit后却用了C索引，导致速度变慢！
由于C索引在其他查询需要用到，不可能删除，暂时没找到很好的解决办法，最后用了一个比较曲折的方式：
基于实际情况，group by 后，C是唯一的，因此我在order by后面加上一个条件D（即Where A or B group by C order by C,D），这样做并不会对结果的顺序造成任何影响，同时不符合C索引的使用条件，进而使MySQL用回A+B的联合索引
期望有更好的答案，7天后再结帖