写业务 SQL 时，count(*)、count(1)、count(id)、count(column) 看起来都能统计数量，但它们表达的语义并不完全一样。很多争论最后会变成“哪个更快”，实际开发里更应该先问：我到底是在统计行数，还是统计某个字段非空的数量。
这篇把 MySQL 里常见的 count 写法和表维护经验整理一下，重点放在日常开发能直接用上的判断。
先分清统计目标
如果目标是统计满足条件的行数，优先写：
select count(*) from orders where status = 'PAID';count(*) 的语义最明确：统计结果集行数。MySQL 并不会真的把所有字段都取出来再数一遍，InnoDB 会按行扫描并让 Server 层累加。
如果写成：
select count(1) from orders where status = 'PAID';它的实际效果通常和 count(*) 非常接近。对于 InnoDB，count(*) 和 count(1) 没有必要为了性能刻意区分。
真正需要小心的是：
select count(email) from users;这不是统计表有多少行，而是统计 email 不为 NULL 的行数。如果 email 允许为空，结果可能小于总行数。
count(id) 不一定比 count(*) 更值得写
有些人习惯写：
select count(id) from users;如果 id 是主键且必定非空，它的结果和 count(*) 一样。但从语义上看，count(*) 更直接，也更不容易让后来维护的人误以为你只关心某个字段。
经验上可以这样记：
- 统计行数：写
count(*)。 - 统计某字段非空数量：写
count(column)。 - 不为了“看起来性能更好”把
count(*)改成count(1)或count(id)。
count 慢时，先看过滤条件和索引
count(*) 本身不是慢的根因。真正影响速度的，通常是扫描范围太大、过滤条件没有合适索引，或者统计口径要求实时精确。
比如：
select count(*) from order_log where created_at >= '2026-07-01';如果 created_at 没有索引，MySQL 只能扫大量数据。更合理的做法是为高频统计条件设计索引，或者把统计口径拆成离线汇总、缓存计数、分区表等方案。
日常排查可以按这个顺序：
- 用
explain看访问类型、索引和预估扫描行数。 - 确认 where 条件是否能走索引。
- 判断统计是否必须实时精确。
- 对高频大表统计考虑汇总表或异步计数。
表删除数据后，空间不一定马上变小
很多人第一次遇到表空间问题，会以为删除一半数据后，磁盘文件应该立刻缩小。实际上 MySQL 删除数据后，底层空间可能只是被标记为可复用，并不会马上归还给操作系统。
这意味着：
- 表内后续插入可以复用部分空间。
- 文件大小不一定跟随
delete立刻下降。 - 大量删除后可能出现碎片，影响空间利用和部分访问效率。
是否需要整理，要看表引擎、表大小、写入频率、业务窗口和可接受的锁影响，不能只看到文件没变小就立刻在线上执行重操作。
optimize table 要谨慎使用
OPTIMIZE TABLE 可以用于整理表空间和索引碎片，但它不是可以随手执行的万能清理命令。
执行前至少确认几件事：
- 表是否很大，执行时间和锁影响能否接受。
- 当前 MySQL 版本和存储引擎会如何处理该命令。
- 是否有主从复制、备份、业务高峰期等额外影响。
- 是否可以在低峰期执行，或先在从库、测试库评估。
对于写入频繁的大表，更常见的思路不是频繁 optimize table，而是提前设计归档、分区、冷热拆分或按时间滚动清理。
实用结论
写 count 时先保持语义清楚：统计行数用 count(*)，统计非空字段用 count(column)。当 count 变慢，不要纠结 * 和 1，而要看过滤条件、索引、扫描范围和统计口径。
表维护也是同理。删除数据后文件不立刻变小很正常，真正需要处理的是碎片、空间复用和业务窗口。OPTIMIZE TABLE 可以作为工具箱里的一个选项，但上线前必须评估影响。
