mysql - MYSQL 统计二十九万条数据要13.96秒正常吗？

Question

SELECT count(*) FROM `t_order_old`

二十九万条数据要13秒多，是不是有点久？这个语句也没办法优化了吧？

Answer 1

count(*)这种东西还是尽量别用，就算你折腾一下1秒内出了结果，但是加上条件、以后数据量更大的时候一样出问题。不如把需要的统计结果单独存一下，在更新时同步维护统计数据就行了。
懒得写代码的话就mysql里面直接挂触发器，比较省心（也避免业务逻辑复杂化）。
典型用例就是文章的回复数量字段，取这个值明显比每次都count强的多。

Answer 2

MySQL 统计二十九万条数据需要13.96秒确实不是一个理想的性能表现。但是否“正常”取决于多个因素，如硬件性能、数据库设计、索引结构、查询优化、当前的系统负载等。

对于SELECT count(*) FROM t_order_old这样的查询，以下是一些建议和优化措施：

1. 确保表有适当的索引：虽然对于COUNT(*)操作，MySQL通常不使用索引（因为它需要计算所有行），但确保其他查询的索引是存在的并且维护良好的。
2. 考虑使用近似值：如果你不需要精确计数，并且可以接受一些误差，那么可以使用SHOW TABLE STATUS来获取表的近似行数。

SHOW TABLE STATUS LIKE 't_order_old';

查看返回的Rows列。

3. 检查硬件和配置：确保MySQL服务器有足够的RAM来缓存常用数据和索引。同时，检查磁盘I/O性能，因为这可能会成为瓶颈。
4. 考虑使用缓存：如果这是一个频繁运行的查询，并且数据不经常更改，那么考虑在应用程序级别缓存结果。
5. 优化数据库设计：确保表结构是合理的，并且没有不必要的数据冗余。
6. 考虑使用更快的存储引擎：例如，InnoDB和MyISAM有不同的性能和特性。InnoDB通常提供更好的事务支持和行级锁定，但MyISAM在某些只读或大量读取的工作负载下可能更快。
7. 查看查询执行计划：使用EXPLAIN关键字来查看MySQL如何执行你的查询，并找出可能的瓶颈。

EXPLAIN SELECT count(*) FROM t_order_old;

8. 定期优化和清理：使用OPTIMIZE TABLE命令来重新组织表和索引，以及定期清理旧数据和不必要的数据。
9. 升级MySQL版本：如果你使用的是较旧的MySQL版本，考虑升级到最新版本，因为新版本通常包含性能改进和修复。
10. 考虑使用分布式数据库：如果数据量继续增长并且性能成为问题，那么可能需要考虑使用分布式数据库解决方案，如分片、分区或数据库集群。

最后，对于SELECT count(*) FROM t_order_old这样的查询，如果表中有很多行并且性能是一个问题，那么通常没有太多的优化空间，除了上述建议之外。但是，确保你已经尝试了所有的基本优化步骤，并且考虑了硬件和配置因素。