SQL报表多字段统计变慢的核心原因是查得太多、算得太杂，需围绕查询目标精简字段，区分展示字段与统计依据字段，严格按GROUP BY和聚合函数反推必需字段，避免SELECT *或冗余列导致的IO、网络与内存开销。
SQL报表中多字段统计变慢，核心原因常是“查得太多、算得太杂”。字段压缩与裁剪不是简单删列，而是围绕查询目标，精简数据传输、减少计算开销、规避隐式转换和无效聚合。关键在区分“展示字段”和“统计依据字段”，前者可压可裁，后者需保精度、控粒度。
只查真正参与统计的字段
常见误区：SELECT * 或 SELECT 所有业务字段后再在应用层做汇总。这会导致大量无用数据从磁盘读取、经网络传输、被内存加载，严重拖慢响应。应严格按GROUP BY + 聚合函数反推必需字段。
- 例如要统计“各城市销售额TOP3商品”，只需 city、product_name、sales_amount 三字段，无需 customer_id、order_time、remark 等无关列
- 用 EXPLAIN 查看执行计划，确认 Extra 列不含 “Using temporary” 或 “Using filesort” —— 这往往意味着字段冗余引发中间临时表膨胀
- 视图或子查询中提前过滤和投影，比在最外层 SELECT 中留着所有字段再靠 WHERE 硬筛更高效
用紧凑类型替代宽字段，尤其避免TEXT/BLOB参与GROUP BY
字符型字段长度直接影响排序与哈希分组性能。VARCHAR(500) 和 VARCHAR(50) 在索引、内存分组、临时表存储上开销差异显著；TEXT 类型无法建索引，强制触发磁盘临时表。
- 将长描述字段（如 product_desc）移出统计SQL，改用关联ID查详情（用 JOIN + 小表驱动）
- 对枚举类字段（如 status、category），用 TINYINT 或 CHAR(2) 替代 VARCHAR(20)，节省存储+加速比较
- 日期类统计统一转为 DATE 或 INT(YYYYMMDD) 格式分组，避免 DATETIME 字段带秒级精度导致分组键膨胀
聚合前先裁剪高基数/低价值维度
某些字段（如 user_agent、url_path、trace_id）基数极高、无业务聚合意义，却常被误加进 GROUP BY，使结果行数暴增、内存耗尽、甚至OOM。
- 检查 GROUP BY 列表：去掉仅用于展示、不参与逻辑分类的字段；若必须显示，改用 MAX() / MIN() / ANY_VALUE() 包裹（MySQL 5.7+ strict mode 下需显式声明）
- 对IP、手机号等敏感字段，统计时用 SUBSTRING(ip, 1, 7) 或 LEFT(phone, 3) 做粗粒度归并，兼顾可读性与性能
- 用 COUNT(DISTINCT ...) 替代 GROUP BY + COUNT(*) 当仅需去重数量——避免生成百万级中间分组结果集
用物化中间结果替代重复计算
当同一张大表被多个字段组合反复统计（如按日+按周+按渠道），每次全表扫描代价高昂。可预先按最小时间粒度（如小时）或核心维度（如 channel_id + region）做轻量聚合，存为汇总表。
- 每日凌晨跑一次 INSERT INTO summary_daily SELECT date_trunc('day', log_time), channel, COUNT(*), SUM(amount) FROM raw_log GROUP BY 1,2
- 报表SQL直接查 summary_daily，避免实时解析原始日志字段（如JSON_EXTRACT、REGEXP_SUBSTR）
- 对动态条件（如自定义时间范围），用 WITH RECURSIVE 或窗口函数替代多层嵌套子查询，减少字段重复展开
字段压缩与裁剪本质是做减法思维：让SQL只搬运和处理它真正需要的部分。不复杂但容易忽略。
