MySQL count(*) 性能优化

很多人认为count查询非常快,但是在加上筛选条件那就是未必的了。测试：user表中4000w数据

为什么统计全部速度快,不统计全部却慢了？

因为mysql默认已经统计过表中的总记录了，所以查询非常快

假设需要查询数据中user表id大于1000的数据，如何快速查询？(上面的查询用时7秒!)

原理：需要id大于1000的人数=总人数-id小于1000的人数(总人数mysql秒完成,id小于1000的人数记录少查询快)

以上的方法只是解决了部分场景，假如现在需要统计用户注册渠道呢？假设注册渠道有QQ和微信，并且2种渠道注册人数一致，数据达到百万。

那么 select count( ) from user where way='qq'和 select count( ) from user where way<>'qq' 无区别.

这种情况就建议建立统计表,用户注册事件发生即可+1 *** 作.

笔者目前在负责一个简单的Spring Boot项目，该项目有一个 *** 作日志的功能。在分页查询 *** 作日志时，需要查询日志的记录数。日志记录也不大，23W左右，比起其他大项目一两百W，少很多了。但是，令人困惑的是，使用count(*)查询总数时，总是十分缓慢，在20s左右，使得打开 *** 作日志非常慢。

于是我改成了count(1)、count(id)，然而都不行。

网上资料说MySQL对count(*)做了特别的优化，按理来说应该是最快的，然而三个都不约而同的非常慢。

解决方案是，为ID加了个唯一键：

之后再使用count(*)便能正常查询了：

对于这个问题的原因，依旧没能想明白为什么。欢迎大家相互讨论~

---