应使用LOWER()或UPPER()函数对分组字段统一大小写后再GROUP BY，如SELECT LOWER(name), COUNT(*) FROM t GROUP BY LOWER(name)，并用MIN()/MAX()保留原始样例值。
GROUP BY 字段区分大小写导致重复分组怎么办
默认情况下，大多数数据库（如 PostgreSQL、SQL Server）对 GROUP BY 中的字符串字段是区分大小写的，'Apple' 和 'apple' 会被视为不同值，各自生成一行聚合结果。这不是 bug，而是字符集和排序规则（collation）的正常行为。
如果你期望把它们合并统计，核心思路不是“关闭大小写敏感”，而是“在分组前统一大小写”：
- 用
LOWER()或UPPER()函数包裹分组字段，确保所有值归一化后再分组 - 注意：函数处理后的字段不能直接用于
SELECT原始值展示，需额外保留原始字段或用MIN()/MAX()提取代表性值 - MySQL 若使用
utf8mb4_0900_as_cs这类大小写敏感排序规则，也会出现该问题；而默认的utf8mb4_0900_as_ci是不区分的，但不可依赖——显式转换更可靠
PostgreSQL 中用 LOWER() 实现大小写无关分组
PostgreSQL 默认区分大小写，且不支持在 GROUP BY 中直接指定 collation（除非用 COLLATE "C" 强制二进制比较，但这反而更严格）。稳妥做法是转换后分组：
SELECT LOWER(product_name) AS name_lower, COUNT(*) AS cnt, MIN(product_name) AS example_name -- 拿一个原始样例，避免全变成小写输出 FROM products GROUP BY LOWER(product_name);
注意：LOWER(product_name) 必须出现在 GROUP BY 中，且不能只写 product_name——否则报错 column "products.product_name" must appear in the GROUP BY clause。
MySQL / SQL Server 中能否用 COLLATE 忽略大小写
可以，但有风险：它依赖具体排序规则是否可用，且可能影响索引使用或跨库兼容性。
- MySQL 示例：
GROUP BY product_name COLLATE utf8mb4_general_ci（_ci表示 case-insensitive） - SQL Server 示例：
GROUP BY product_name COLLATE SQL_Latin1_General_CP1_CI_AS - 问题：如果字段本身定义为
COLLATE ..._CS（case-sensitive），强制指定_CI可能触发隐式转换，导致索引失效 - 更安全的做法仍是用
LOWER()——语义明确、跨引擎一致、优化器也容易识别
聚合后想还原首字母大写等格式怎么办
别在 GROUP BY 阶段还原——那会再次拆分分组。应该在聚合完成后再做格式化：
SELECT INITCAP(name_lower) AS formatted_name, -- PostgreSQL（注意：MySQL 无 INITCAP，需 CONCAT(UPPER(LEFT(...)), LOWER(RIGHT(...)))） cnt FROM ( SELECT LOWER(product_name) AS name_lower, COUNT(*) AS cnt FROM products GROUP BY LOWER(product_name) ) t;
关键是：大小写归一必须发生在 GROUP BY 阶段；格式美化必须放在外层查询。混在一起会导致逻辑断裂或性能下降。
真正容易被忽略的是：当字段含空格、不可见字符（如 \t、\r）或全角/半角字母时，LOWER() 仍会认为它们不同。遇到聚合结果比预期多，先 SELECT product_name, LENGTH(product_name), DUMP(product_name)（Oracle）或 HEX(product_name)（MySQL）查编码细节。
