SQL日报周报慢的核心是时间范围扫描大、索引未覆盖、分区未生效；应确保分区键与查询条件严格对齐、避免函数作用于索引列、统一使用标准datetime格式传参、字段与参数类型严格一致，并通过预聚合建轻量汇总表优化周报性能。
SQL日报、周报统计慢，核心问题常出在时间范围扫描大、索引未覆盖、分区未生效。解决关键不是堆资源，而是让查询只读必要分区 + 一次索引到位。
时间字段必须建分区，且分区键要和查询条件严格对齐
比如按天分区，表用 PARTITION BY RANGE (TO_DAYS(create_time))，但查询写成 WHERE create_time >= '2024-05-01' AND create_time 才能命中分区。若写成 DATE(create_time) BETWEEN ... 或 YEAR(create_time)=2024，MySQL 无法下推分区裁剪，全分区扫描就回来了。
- 分区字段必须是独立列，不能包裹函数
- 范围查询务必用左闭右开（如
>= AND <），避免边界截断或跨区误判 - 检查是否真正走分区：执行 EXPLAIN PARTITIONS，看
partitions列是否只列出目标分区
统计查询的 WHERE + GROUP BY + SELECT 字段，要被单个联合索引全覆盖
例如日报统计：SELECT COUNT(*), SUM(amount), AVG(status) FROM order_tab WHERE create_time BETWEEN ? AND ? GROUP BY shop_id。理想索引是：(create_time, shop_id, amount, status) —— 时间字段放最左保证范围扫描高效，shop_id 紧随其后支撑分组，amount 和 status 放最后使索引“覆盖”，避免回表。
- 不要只建 (create_time)，也不要用 (shop_id, create_time)：前者无法加速分组，后者破坏时间范围扫描效率
- 聚合函数涉及的列（SUM/AVG/MAX等字段）必须包含在索引中，否则仍需回表查原始行
- 用 EXPLAIN 看
Extra是否含Using index，没有就说明没覆盖
避免隐式类型转换和函数操作导致索引失效
常见陷阱：WHERE create_time >= STR_TO_DATE('20240501', '%Y%m%d') —— 函数作用于索引列，索引直接失效；或 create_time 字段是 datetime，但传入字符串 '2024-05-01' 没带时分秒，MySQL 可能自动补 00:00:00 导致精度偏差，影响分区和索引选择。
- 参数统一用标准 datetime 格式传递（如 '2024-05-01 00:00:00'），不依赖数据库隐式转换
- 字段类型和查询值类型严格一致：datetime 字段就传 datetime，不要用 int 时间戳或字符串混用
- 用 SHOW WARNINGS 查看优化器是否发出“type conversion”警告
周报场景可预聚合，减少实时计算压力
日报可接受秒级延迟，但周报（尤其历史多周对比）反复扫描7天×N个月数据，IO 和 CPU 开销陡增。建议建轻量汇总表：每天凌晨跑一次 INSERT INTO report_weekly_summary … SELECT … WHERE create_time IN (last_monday..this_sunday)，按 week_start_date + shop_id 主键。
- 汇总表数据量小、结构扁平，周报查询变成简单主键或二级索引点查
- 配合事件调度器（EVENT）或定时任务自动刷新，避免人工干预遗漏
- 首次上线可用 REPLACE INTO 或 INSERT ON DUPLICATE KEY UPDATE 保障幂等
