COUNT() 更稳，因其直接利用元数据或索引行计数，而 COUNT(字段) 需逐行判空，既慢又有语义偏差；监控统计应优先用 COUNT() + WHERE，必要时用 COALESCE 或 CASE 显式处理非空逻辑。
为什么 COUNT(*) 比 COUNT(字段) 在监控中更稳
监控场景下，查“当前活跃连接数”或“每分钟错误日志条数”，首要目标是快且准。COUNT(*) 直接走表的元数据或索引行计数（尤其 InnoDB 的聚簇索引），而 COUNT(字段) 会逐行判断该字段是否为 NULL，多一层判断开销。在高并发写入、无主键或字段允许 NULL 的表上，差异明显。
常见错误现象：COUNT(status) 统计接口调用成功数，但 status 字段有大量 NULL（比如未更新状态的脏数据），结果比预期少——这不是性能问题，是语义偏差。
- 监控类统计一律优先用
COUNT(*)，再加WHERE过滤条件限定范围 - 真要统计非空值，明确写成
COUNT(COALESCE(status, ''))或SUM(CASE WHEN status IS NOT NULL THEN 1 ELSE 0 END)，避免歧义 - 对大表做
COUNT(*)仍慢？说明没走覆盖索引——给监控常用的 WHERE 条件字段建联合索引，例如CREATE INDEX idx_log_time_level ON error_log (created_at, level);
GROUP BY + 时间窗口切分时，别让 MySQL 自动截断秒级精度
做“每5分钟错误率趋势”，习惯写 GROUP BY DATE(created_at), HOUR(created_at), MINUTE(created_at) DIV 5，看似合理，实则埋雷：当 created_at 是 DATETIME 类型，MINUTE(created_at) DIV 5 会把 00:04 和 00:05 都归到同一组，但 00:04:59 和 00:05:00 被拆开——时间窗口错位。
正确做法是用整数时间戳对齐窗口起点：
SELECT FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(created_at) / 300) * 300) AS window_start, COUNT(*) AS total, COUNT(CASE WHEN level = 'ERROR' THEN 1 END) AS errors FROM error_log WHERE created_at >= NOW() - INTERVAL 1 HOUR GROUP BY window_start;
-
FLOOR(UNIX_TIMESTAMP(...) / 300) * 300确保所有落在 [00:00, 00:04:59] 的记录都归到 00:00 窗口 - 避免用
STR_TO_DATE或嵌套DATE_FORMAT，函数调用开销大，且无法利用created_at字段索引 - 如果表有分区（按天分区），WHERE 中必须带
created_at范围，否则可能触发全分区扫描
AVG() 和 PERCENTILE_CONT() 在延迟监控里不能混用
查“平均响应时间”用 AVG(latency_ms) 很自然，但一旦有毛刺（如某次 GC 导致 10s 延迟），平均值就被拉高，掩盖真实水位。SRE 场景下，P95/P99 延迟才是关键指标。
MySQL 8.0+ 支持窗口函数，但 PERCENTILE_CONT 不可用；PostgreSQL 可用，但要注意它默认返回 double precision，和原始 integer 延迟字段类型不一致，可能引发隐式转换导致索引失效。
- MySQL 用户用
GROUP_CONCAT+SUBSTRING_INDEX曲线救国（仅限中小数据量）：SUBSTRING_INDEX(SUBSTRING_INDEX(GROUP_CONCAT(latency_ms ORDER BY latency_ms), ',', FLOOR(0.95 * COUNT(*) + 1)), ',', -1) - PostgreSQL 用户优先用
percentile_disc(0.95) WITHIN GROUP (ORDER BY latency_ms)，它返回离散值，类型与输入一致，不触发隐式转换 - 无论哪种，务必在
latency_ms上建索引，并限制查询时间范围——全表算 P95 是自找死路
监控 SQL 跑得慢？先看执行计划里有没有 Using filesort 或 Using temporary
加了 ORDER BY timestamp DESC LIMIT 20 查最新告警，却跑了 8 秒——不是数据量大，是执行计划里出现 Using filesort。这意味着 MySQL 拿到 WHERE 结果后，还得额外排序，无法利用索引有序性。
根本原因常是复合索引顺序和查询条件/排序不匹配。例如索引是 (status, created_at)，但查询写 WHERE status = 'ERROR' ORDER BY created_at DESC，这时能用上索引；可如果写成 WHERE app_name = 'api' ORDER BY created_at DESC，索引就完全失效。
- 监控类查询的索引，必须把高频过滤字段放最左，排序字段紧随其后，例如
(service_name, status, created_at) - 用
EXPLAIN FORMAT=JSON看key_length是否充分利用索引长度，filtered值低于 10 表示索引选择性差 - 避免在 WHERE 中对字段用函数：
WHERE DATE(created_at) = CURDATE()会让索引失效，改用WHERE created_at >= CURDATE() AND created_at
复杂点在于：监控 SQL 往往要兼顾多个维度（服务名、状态、级别、时间），但单个索引无法覆盖全部组合。与其堆砌一堆单列索引，不如根据实际慢查日志，按访问频次建 2–3 个最常用组合索引——剩下的，宁可加 FORCE INDEX 也别让优化器乱选。
