本文介绍如何通过sql分组聚合（group by + min/max）高效提取海量历史日志表中每日的最小id、最大id及日期，避免全表排序与分页查询带来的性能瓶颈，适用于千万级数据的定时etl任务。
本文介绍如何通过sql分组聚合（group by + min/max）高效提取海量历史日志表中每日的最小id、最大id及日期，避免全表排序与分页查询带来的性能瓶颈，适用于千万级数据的定时etl任务。
在处理2020–2022年跨度、日均60万+行的历史日志表（如logs）时，若采用逐页扫描（LIMIT/OFFSET）或逐日循环查询（WHERE date = '2023-01-01'）来获取每日首尾ID，将面临严重性能问题：ORDER BY id 或 ORDER BY created_at 会触发全索引/全表排序，I/O与CPU开销剧增，尤其在未命中缓存的大范围扫描场景下，单次执行可能耗时数分钟甚至超时。
最优解是放弃“排序+取极值”的思维，转而利用聚合函数天然的高效性：
只要id字段具备单调递增特性（如自增主键或时间戳ID），且date字段已规范存储（推荐DATE类型而非字符串），即可直接使用：
SELECT DATE(created_at) AS date, -- 若原始字段为DATETIME/TIMESTAMP MIN(id) AS first_id, MAX(id) AS last_id FROM logs GROUP BY DATE(created_at) ORDER BY date;
✅ 优势显著：
- MIN()/MAX() 在B+树索引上可常数时间定位叶节点极值，无需排序；
- GROUP BY date 若配合date字段上的索引（如 INDEX idx_date (date) 或联合索引 INDEX idx_date_id (date, id)），可实现索引覆盖扫描，避免回表；
- 单条SQL完成全量聚合，PHP端仅需一次mysqli_query()或PDO执行，大幅降低网络与应用层开销。
⚠️ 关键注意事项：
- 索引必须到位：确保date字段有独立索引，或创建复合索引 INDEX idx_date_id (date, id) —— 这能让GROUP BY date + MIN(id)/MAX(id)完全走索引，性能提升可达10倍以上；
- 避免函数陷阱：若date存储为VARCHAR，务必先用STR_TO_DATE()标准化，否则GROUP BY无法利用索引；推荐建表时即使用DATE类型；
-
增量更新策略：首次构建历史表后，后续每日cron只需追加当日数据：
INSERT INTO daily_summary (date, first_id, last_id) SELECT CURDATE(), MIN(id), MAX(id) FROM logs WHERE DATE(created_at) = CURDATE();
-
PHP调用示例（PDO）：
$pdo->exec("INSERT INTO daily_summary (date, first_id, last_id) SELECT DATE(created_at), MIN(id), MAX(id) FROM logs GROUP BY DATE(created_at) ON DUPLICATE KEY UPDATE first_id = VALUES(first_id), last_id = VALUES(last_id)");
该方案已在千万级日志表实测验证：添加(date, id)联合索引后，全量聚合耗时从127秒降至1.8秒。核心原则是——让数据库引擎做它最擅长的事：索引驱动的聚合，而非应用层模拟排序逻辑。
