直接按原始字段group by会将'alice'和'alice'分为两组，因collation决定大小写敏感性；需通过lower()临时归一化或修改字段collation为_ai_ci实现合并分组。
直接按原始字段 GROUP BY 会把 'Alice' 和 'alice' 当成两组——这不是 bug，是 collation 决定的默认行为。要合并，必须统一比较基准。
先确认字段的排序规则（collation）是否区分大小写
执行 SHOW FULL COLUMNS FROM users LIKE 'name';，看 Collation 列：
-
utf8mb4_0900_as_cs、utf8mb4_bin→ 大小写敏感，GROUP BY name必然拆开 -
utf8mb4_0900_ai_ci、utf8mb4_general_ci→ 不区分大小写，GROUP BY name自动合并
注意：你看到的 collation 是列定义值，但 JOIN 或子查询中若涉及多表，实际生效规则可能被隐式覆盖——别只信 SHOW 命令结果，要实测。
临时统一大小写再分组（最通用，跨库可用）
用 LOWER() 或 UPPER() 包裹字段，强制归一化：
SELECT LOWER(name) AS norm_name, COUNT(*) FROM users GROUP BY LOWER(name);
关键点：
- 必须两边都用函数：如果只是
GROUP BY name但SELECT LOWER(name)，分组仍按原始大小写进行 - 该写法会让
name上的普通索引失效（优化器无法下推），大数据量时慎用 - NULL 值经
LOWER()后仍是 NULL，会被单独分到一组，符合预期 - 若字段含全角空格或不可见字符，先
TRIM()：GROUP BY LOWER(TRIM(name))
建函数索引提升性能（MySQL 8.0+ / PostgreSQL）
如果高频查询且不能改 collation，优先建表达式索引，而非每次跑函数：
-- MySQL CREATE INDEX idx_lower_name ON users (LOWER(name));
-- PostgreSQL CREATE INDEX idx_lower_name ON users (LOWER(name));
建完后，GROUP BY LOWER(name) 就能走索引了。但注意：
- MySQL 5.7 不支持函数索引，只能退回到
LOWER()+ 全表扫描 - PostgreSQL 的
ILIKE不能替代这个索引，它不走 B-Tree 索引，只适合模糊匹配 - 索引名和字段名无强制关联，但建议命名带
lower提示用途，避免后续误删
改列 collation（一劳永逸，但需权限和评估）
如果业务允许且你有 DDL 权限，直接改字段 collation 最省事：
ALTER TABLE users MODIFY name VARCHAR(100) COLLATE utf8mb4_0900_ai_ci;
风险点：
- 修改 collation 可能触发全表重建（尤其大表），锁表时间长
- 已有索引会自动重建，但应用层若依赖大小写敏感逻辑（比如密码哈希校验），会出问题
- MySQL 与 PostgreSQL 的 collation 名称不兼容，跨库迁移时得重配
- 某些旧版本（如 MySQL 5.6）不支持在线 DDL，必须停写
真正容易被忽略的是：collation 修改后，已存在的数据不会“重排序”，但后续所有比较、分组、索引查找都按新规则生效——这意味着历史数据的分组行为会突变，上线前必须在影子库验证。
