临时表字段类型不一致会导致group by隐式转换和索引失效，应显式建表并定义字段类型；动态拼接group by时select与group by字段必须完全一致，包括函数表达式；where应在插入阶段过滤行级数据，having仅用于聚合后筛选；分组前须按where→group by→聚合字段顺序创建索引。
临时表字段类型不一致导致GROUP BY失效
直接 CREATE TEMPORARY TABLE AS SELECT 容易让字段类型“悄悄变形”：比如源表 varchar(200) 变成 text，或表达式结果被推断为 varchar(max)（SQL Server）或 longtext（MySQL），后续 GROUP BY 会触发隐式转换，索引完全失效。
实操建议：
- 用
CREATE TEMPORARY TABLE t (col1 VARCHAR(200), col2 INT, ...)显式建表，再INSERT INTO t SELECT ... - PostgreSQL 中临时表默认无索引，分组前必须手动加：
CREATE INDEX ON t (group_col) - MySQL 不支持
#temp语法，但CREATE TEMPORARY TABLE后无法用LIKE复制结构，字段长度和 NULL 约束得逐个核对
动态拼接GROUP BY时SELECT与GROUP BY字段不匹配
前端传入分组维度 ['region', 'product_type']，但 SQL 拼错成 SELECT region, SUM(sales) GROUP BY region —— 这在 MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY 下直接报错：Expression #1 of SELECT list is not in GROUP BY clause。
实操建议：
- 拼 SQL 时，
SELECT列表里的非聚合字段必须和GROUP BY子句**完全一致**，包括函数表达式：比如SELECT UPPER(region), COUNT(*) FROM t GROUP BY UPPER(region) - 禁止把条件逻辑只写在
SELECT里却漏掉GROUP BY，例如CASE WHEN region IN ('华东','华南') THEN '南方' ELSE '其他' END必须原样复制进GROUP BY - 关掉
ONLY_FULL_GROUP_BY是掩耳盗铃，不是解决办法
临时表里该用WHERE过滤而不是HAVING
临时表存的是中间结果，容易误以为“数据已经筛过了”，就把业务条件全堆到 HAVING。但 HAVING 是聚合后执行，会导致无效计算——比如查“销售额 > 10w 的区域”，写成 HAVING SUM(sales) > 100000 会让数据库先算出所有区域的 SUM，再过滤；而 WHERE sales > 100000（原始行级过滤）能提前丢弃大量无关行。
实操建议：
-
WHERE用于行级筛选，HAVING仅用于对聚合结果再筛选 - 临时表含
NULL时，WHERE region IS NOT NULL和HAVING COUNT(region) > 0效果完全不同：前者剔除 NULL 行，后者只排除整组计数为 0 的分组 - 多源
UNION构建的临时表，务必在INSERT INTO temp SELECT ...阶段就加好WHERE条件，别留到后续查询再补
临时表分组前没建索引或索引顺序错
EXPLAIN 出现 Using temporary 就是确诊书：MySQL 正在写临时表，内存不够就落盘；PostgreSQL 中 Hash Agg 节点出现 Spill to disk 也说明哈希表爆了。这不是调大 tmp_table_size 或 work_mem 能解决的，核心是索引没对上。
实操建议：
- 索引顺序必须是：
WHERE 字段 → GROUP BY 字段 → 聚合依赖字段（如WHERE status = 'paid' GROUP BY user_id，索引应为(status, user_id)） - 避免在
GROUP BY里用函数：GROUP BY DATE(created_at)会让索引失效，改用预计算列 + 索引 - 临时表创建后立即建索引，别等查询时才想起来；PostgreSQL 中索引名不用加唯一前缀，但得确保
CREATE INDEX执行成功（检查pg_indexes）
