SELECT COUNT(*) FROM orders WHERE status = 1; ALTER TABLE orders ADD INDEX idx_status (status); -- 近似值 SELECT table_rows FROM information_schema.tables WHERE table_name = 'orders';
后台首页显示总记录数,每次打开都要等好几秒,表数据一直在增长。这类现象通常不是突然出现的,往前翻半天日志能看到苗头。
追下去是这么回事:count 需要扫描索引或全表确认行数,数据量大时无法避免扫描成本。
「MySQL count 优化」排查到最后往往是很小的一处差异,前面那些复杂猜测可以先放一放。监控和日志的时间要对上,时区不一致会多绕很大一圈。
临时改动用注释写上日期和原因,过两周自己都记不清为什么这么写。动手前把原文件复制一份带时间戳,出问题立刻换回去,比现场分析快得多。
一次只改一处,改完立刻验证,几个改动叠在一起,出问题就说不清是谁导致的。先做最小复现,能稳定跑出来的问题,排查成本会低一个数量级。
处理上按这个顺序:用近似值或缓存计数;按条件统计时建立覆盖索引;把总数改为定时任务写入统计表。
确认没问题再收工,首页加载时间明显下降,统计数字与业务预期偏差在可接受范围。