1、于是我改成了count(1)、count(id)，然而都不行。网上资料说MySQL对count(*)做了特别的优化，按理来说应该是最快的，然而三个都不约而同的非常慢。
成都创新互联公司坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站建设、网站制作、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的叙永网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！
2、任何情况下SELECT COUNT(*)FROM xxx 是最优选择；尽量减少SELECT COUNT(*)FROM xxx WHERE COL = ‘xxx’这种查询；杜绝SELECT COUNT(COL)FROM tablename WHERE COL = ‘xxx’的出现。
3、根据主键会查到整条数据 根据辅助索引只能查到主键，然后必须通过主键再查到剩余信息。所以如果要优化count(*)操作的话，我们需要找一个短小的列，为它建立辅助索引。
最有效的解决方法是需要多少记录就查询多少记录，通常会在查询后面加上LIMIT，即： 分页查询。
查看建立索引前面的返回的结果。假如没有索引的话，explain会显示返回查询全表的数据自然会很慢了。
利用表分区：这个是推荐的一个解决方案，不会带来重写逻辑等，可以根据时间来进行表分区，相当于在同一个磁盘上，表的数据存在不同的文件夹内，能够极大的提高查询速度。
如果服务器本地快，但页面查询慢，那就排除了性能问题，考虑网络问题与页面查询语句调用的驱动模块是否有问题。检测网络连接速度，如慢尝试更换网线。网络连接速度正常，则尝试更换调用的驱动包，重新下一个或换一个版本。
最近一段时间由于工作需要，开始关注针对Mysql数据库的select查询语句的相关优化方法。
第三，如果实在搞不定，需求方一定要按照数据库容易接受的方式去写SQL，这个成本会下降的非常快，这个是常规的MySQL慢的诊断思路。
可以看到执行时间变成了 0.67s。整理 我们诊断的关键点如下：\ 对于 information_schema 中的元数据表，执行计划不能提供有效信息。\ 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。
软件，mysql是不是没有设置好，数据库设计方面等，语言，SQL语句写法。下面是一些优化技巧。对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
首先确认什么操作最消耗时间。是数据查询，还是服务器之间的传输。如果查询慢，需要根据你实际的数据模型优化sql，增加索引。具体操作百度。如果传输慢，想办法把几十次请求放到一次请求里面完成，减少服务器之间的交互。
MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句1，slow_query_log这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句。2，long_query_time当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短。
