临时表创建后必须显式指定字段类型才能安全分组，因select into或create temporary table as可能引发字段类型不一致（如varchar变text、长度截断），导致group by隐式转换失败或索引失效；推荐先create table定义结构再insert select，确保类型、长度、null约束可控。
临时表创建后必须显式指定字段类型才能安全分组
直接 SELECT * INTO #temp FROM ... 生成的临时表，字段类型可能和源表不一致（比如 varchar 变成 text 或长度被截断），导致后续 GROUP BY 时隐式转换失败或索引失效。尤其在 SQL Server 中，SELECT INTO 会继承源列类型，但若源是表达式（如 CONCAT(a,b)），类型可能变成 varchar(max)，严重影响分组性能。
- 推荐用
CREATE TABLE #temp (...)显式建表，再INSERT INTO #temp SELECT ...，确保字段类型、长度、是否允许 NULL 都可控 - MySQL 不支持
#temp语法，要用CREATE TEMPORARY TABLE temp_name AS ...，但注意它不支持LIKE复制结构，字段类型仍需检查 - PostgreSQL 没有会话级临时表别名机制，必须用
CREATE TEMP TABLE，且默认不带索引，大表分组前建议对GROUP BY字段加CREATE INDEX ON #temp (col)
动态分组字段不能拼进 GROUP BY 却漏掉 SELECT 列表
这是动态报表最常报错的地方：Expression #1 of SELECT list is not in GROUP BY clause。临时表本身不改变 SQL 语义规则——只要用了 GROUP BY，所有非聚合字段就必须同时出现在 SELECT 和 GROUP BY 中。
- 如果前端传入分组维度
['region', 'product_type']，拼 SQL 时必须同步生成SELECT region, product_type, SUM(sales)和GROUP BY region, product_type - 禁止在
SELECT里写CASE WHEN region IN ('华东','华南') THEN '南方' ELSE '其他' END却在GROUP BY里只写region——必须把整个表达式复制过去 - MySQL 5.7+ 默认开启
ONLY_FULL_GROUP_BY，关掉它只是掩盖问题，不是解决办法
临时表分组前先过滤再聚合，别让 HAVING 替代 WHERE
临时表里存的是中间结果，容易误以为“反正数据已经筛过了”，就把条件全堆到 HAVING。但 HAVING 是在聚合后才执行，会导致无效计算和逻辑错误。
- 想查“销售额 > 10w 的区域”，必须写
WHERE sales > 100000（原始行过滤），而不是HAVING SUM(sales) > 100000（分组后过滤） - 临时表若含 NULL 值，
WHERE region IS NOT NULL和HAVING COUNT(region) > 0效果完全不同：前者排除 NULL 行，后者只排除整组计数为 0 的分组 - 如果临时表是从多源 UNION 得来，务必在
INSERT INTO #temp阶段就完成基础过滤，避免后续重复扫描
动态列分组必须用 CASE WHEN + 聚合，不能靠 PIVOT 或应用层拼列名
临时表无法真正支持运行时列名变化。所谓“按用户偏好动态分组”，本质是把行转成固定列的汇总值，不是真生成新字段。
- 正确写法是
SUM(CASE WHEN pref_type = 'beverage' AND pref_value = 'coffee' THEN 1 ELSE 0 END) AS likes_coffee，配合GROUP BY user_id - 必须显式写
ELSE 0，否则SUM遇到全 NULL 分支会返回 NULL，不是 0 - 分类值（如
product_type）必须提前确认全集，用SELECT DISTINCT查一遍，漏写的类别不会自动补 0，而是彻底不出现 - SQL Server 的
PIVOT看似动态，但列名必须写死，无法用变量替换，实际仍是静态定义
临时表的“临时”属性容易让人忽略它的物理存在——它照样走查询计划、照样受统计信息影响、照样要面对类型隐式转换和索引缺失问题。分组操作一旦变慢或出错，第一反应不该是“换种写法”，而是去查 DESCRIBE #temp 或 sp_help #temp，确认字段类型和数据分布是否符合预期。
