MySQL没有Count-Column语法，实际只有COUNT()函数；COUNT(col)统计非空值，COUNT(*)统计所有行；海量数据需索引优化、生成列等手段确保精确高效统计。
Count-Column 不是 MySQL 的合法语法，别被误导
MySQL 没有 Count-Column 这个函数或关键字。你在文档、博客或 Stack Overflow 上看到的所谓 “Count-Column” 通常是对 COUNT(column_name) 的误称或口语化简写，容易让人误以为存在一个独立功能。实际能用的只有标准聚合函数 COUNT()，它对非空值（NOT NULL）计数，且会自动跳过 NULL —— 这正是“非空字段精确统计”的底层机制。
COUNT(col) 和 COUNT(*) 在非空统计中的本质区别
想准确统计某列有多少非空值，必须用 COUNT(column_name)，而不是 COUNT(*)。后者统计的是行数，不管字段是否为 NULL。
-
COUNT(*)：统计所有行，包括该列全为NULL的行 -
COUNT(col)：只统计col IS NOT NULL的行，自动过滤NULL - 如果列定义为
NOT NULL，二者结果一致；但海量数据下，业务字段往往允许NULL，这时差异就致命 - 执行计划上，
COUNT(col)可能触发索引覆盖（尤其当col有单列索引且非空比例高），而COUNT(*)在 InnoDB 中常走聚簇索引，开销更大
海量数据下避免全表扫描的实操要点
直接 SELECT COUNT(content) FROM huge_table 在亿级表上可能卡死或超时。关键不是换函数，而是控制访问路径：
- 确保目标列上有有效索引：
CREATE INDEX idx_content ON huge_table (content);—— 即使content允许NULL，B+ 树索引仍能跳过NULL条目（InnoDB 索引不存NULL） - 避免在
COUNT()中使用表达式：COUNT(TRIM(content))或COUNT(IF(content != '', 1, NULL))会强制回表，失去索引优势 - 若只需近似值，可用
SHOW TABLE STATUS LIKE 'huge_table'查Rows字段（误差可达 40%），但无法替代精确非空统计 - 对分区表，可并行查各分区：
SELECT SUM(cnt) FROM (SELECT COUNT(content) AS cnt FROM huge_table PARTITION(p202401) UNION ALL SELECT COUNT(content) AS cnt FROM huge_table PARTITION(p202402)) t;
NULL 值判定逻辑必须与业务定义对齐
数据库里的 NULL 不等于空字符串 ''、零值 0 或字符串 'NULL'。如果你要统计“真正有内容”的字段，仅靠 COUNT(content) 不够：
- 文本字段常见陷阱：
''、' '、'\t\n'都是非NULL但无业务意义的值 - 正确写法应显式排除：
COUNT(CASE WHEN TRIM(content) != '' THEN 1 END)，但注意这无法走索引 - 更优解是建生成列 + 索引：
ALTER TABLE huge_table ADD COLUMN content_nonempty TINYINT GENERATED ALWAYS AS (IF(TRIM(content) != '', 1, 0)) STORED;，再建索引INDEX idx_nonempty (content_nonempty)，最后COUNT()该生成列 - 时间字段要注意：
'0000-00-00'或'1970-01-01'常被当“无效值”，它们不是NULL，得单独过滤
IS NOT NULL，还是业务语义上的“有效值”。前者用 COUNT(col) 直接解决；后者必须前置清洗逻辑或引入生成列，否则索引失效、性能崩塌、结果失真——这些坑在千万级以上数据里，一踩就停服。 
