标准SQL中MINUTE()函数仅提取分钟值（0–59），不能用于按分钟分组统计；正确做法是先将时间戳截断对齐到分钟起点（如PostgreSQL用DATE_TRUNC('minute', t)、MySQL用DATE_FORMAT(t, '%Y-%m-%d %H:%i')），再分组聚合，并确保时间字段有索引。
SQL里没有MINUTE()函数，别被名字骗了
直接说结论：标准SQL（包括PostgreSQL、SQL Server、SQLite）中确实有MINUTE()这样的函数，但MySQL和Oracle压根不提供——它们用的是MINUTE()的替代写法，比如MySQL用MINUTE()是合法的，但Oracle必须用EXTRACT(MINUTE FROM ...)。更关键的是，MINUTE()本身只提取时间字段的分钟数值（0–59），**不能直接用于“按分钟分组统计请求量”**。你真正需要的是时间截断 + 分组聚合。
按分钟分组统计请求的通用写法
核心思路是把原始时间戳“对齐”到最近的分钟起点（例如把'2024-05-12 14:23:47'变成'2024-05-12 14:23:00'），再按这个对齐后的时间分组。不同数据库语法差异大，容易出错：
- PostgreSQL：
DATE_TRUNC('minute', request_time) - MySQL（8.0+）：
DATE_SUB(request_time, INTERVAL SECOND(request_time) SECOND)或更稳的STR_TO_DATE(DATE_FORMAT(request_time, '%Y-%m-%d %H:%i'), '%Y-%m-%d %H:%i') - SQL Server：
DATEADD(MINUTE, DATEDIFF(MINUTE, 0, request_time), 0) - Oracle：
TRUNC(request_time, 'MI')
示例（PostgreSQL）：
SELECT
DATE_TRUNC('minute', request_time) AS minute_slot,
COUNT(*) AS req_count
FROM api_logs
WHERE request_time >= NOW() - INTERVAL '1 hour'
GROUP BY DATE_TRUNC('minute', request_time)
ORDER BY minute_slot;MySQL用户特别注意的两个坑
MySQL 5.7及更早版本不支持DATE_TRUNC()，强行用会报错FUNCTION DATE_TRUNC does not exist；而用MINUTE(request_time)单独提取分钟数（比如全变成23）会导致跨小时/跨天的数据被错误合并。
- ❌ 错误写法（丢失小时/日期信息）：
GROUP BY MINUTE(request_time)→ 所有“23分”的请求全归一组，不管是不是同一小时 - ✅ 正确做法（保留完整时间粒度）：
GROUP BY DATE_FORMAT(request_time, '%Y-%m-%d %H:%i') - ⚠️ 注意时区：
NOW()返回系统时区时间，若日志存的是UTC，需先用CONVERT_TZ()对齐，否则统计窗口偏移
性能敏感场景必须加索引
按分钟分组本质是范围扫描+分组聚合，没索引时全表扫描极慢。尤其当表有千万级请求记录时：
- 必须在时间字段建索引：
CREATE INDEX idx_req_time ON api_logs(request_time); - 如果查询固定时间范围（如最近1小时），索引能生效；但如果用
DATE_FORMAT(request_time, '%Y-%m-%d %H:%i')做分组表达式，MySQL无法直接走索引，建议先过滤再分组 - 高频统计可考虑物化分钟级汇总表，用定时任务每分钟跑一次
INSERT ... SELECT写入预计算结果
实际执行前先EXPLAIN看是否走了索引，别假设它会自动优化。
