直接用 DATE_FORMAT 或 TO_CHAR 会慢得离谱，因为函数包裹 log_time 后数据库无法使用索引，导致全表扫描；应改用分钟对齐表达式（如 MySQL 的 FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(log_time)/60)*60)）配合 log_time 上的 B-tree 索引和按天分区实现高效聚合。
为什么直接用 DATE_FORMAT 或 TO_CHAR 会慢得离谱
对亿级日志表按分钟聚合时，如果直接在 WHERE 或 GROUP BY 里写 DATE_FORMAT(log_time, '%Y-%m-%d %H:%i')（MySQL）或 TO_CHAR(log_time, 'YYYY-MM-DD HH24:MI')（PostgreSQL），数据库无法利用 log_time 上的索引——因为函数包裹后变成了计算列，优化器只能全表扫描。实测某 5 亿行表，这种写法耗时从 8 秒飙到 142 秒。
真正有效的做法是把时间“对齐”到分钟边界，再走范围查询和索引扫描：
- 把原始时间向下取整到最近的分钟：MySQL 用
FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(log_time) / 60) * 60)；PostgreSQL 用log_time - (log_time::time - '00:00'::time) % INTERVAL '1 minute' - 确保
log_time字段有 B-tree 索引（不是函数索引） - 聚合前先用
WHERE log_time >= '2024-01-01' AND log_time 限定大范围，避免扫描无关分区
如何让 GROUP BY 不拖垮执行计划
分钟级聚合最常卡在 GROUP BY 阶段：数据量大时，哈希分组会吃光内存，触发磁盘临时文件，IO 成瓶颈。观察 EXPLAIN 输出中是否出现 Using temporary; Using filesort 就是信号。
两个务实改进点：
- 用
GROUP BY表达式替代别名：写GROUP BY FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(log_time)/60)*60)，而不是GROUP BY minute_bucket（别名在 MySQL 中可能绕过优化） - 限制输出行数：加
LIMIT 1000测试逻辑，确认无误后再去掉；生产环境聚合结果超 10 万行时，考虑加HAVING COUNT(*) > 10过滤低频噪音桶 - 避免在
SELECT中混用非聚合字段（如SELECT log_time, COUNT(*)），否则 MySQL 会强制启用sql_mode=only_full_group_by检查，增加解析开销
分区表 + 分钟对齐 = 真实可落地的组合技
单靠 SQL 优化撑不住日增千万级的日志。必须配合表结构设计：按天分区（PARTITION BY RANGE (TO_DAYS(log_time))），并在每个分区内部，用分钟对齐表达式做二级过滤。
例如查询 2024-05-20 的分钟 PV：
p20240520
- 统一入库用
TIMESTAMP类型（自动转 UTC），查询时用CONVERT_TZ(log_time, '+00:00', '+08:00')（MySQL）或log_time AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'（PostgreSQL）做转换 - 转换后再取整，不要先取整再转换：前者保证每分钟桶严格对齐本地时间，后者会在跨小时边界处漏掉或重复计数
- 验证方法：挑一个含 00:59→01:00 跨越的样本，手动比对转换前后分钟值是否一致
分钟粒度聚合真正的难点不在语法，而在时间对齐方式是否与业务时区语义完全咬合——差 1 秒，就可能让某个关键告警分钟桶空缺。
