若直接按原始字段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后，已有的数据并不会“重新排序”，然而后续所有的比较、分组以及索引查找都会按照新的规则生效。这也就意味着，历史数据的分组行为会发生突变，因此在上线之前，必须要在影子库进行验证。

《夸克》非常好用的免费AI浏览器

下载APP查看