MySQL中DISTINCT性能优化核心是减少扫描行数、避免临时表和文件排序，优先通过索引实现去重；需为DISTINCT字段建立合适索引，慎用GROUP BY替代，避免SELECT *，并借助EXPLAIN分析执行计划。
MySQL 中 DISTINCT 查询容易成为性能瓶颈，尤其在大数据量、无合适索引或涉及多字段去重时。优化核心在于减少扫描行数、避免临时表和文件排序，优先让去重逻辑由索引完成。
确保被 DISTINCT 的字段有高效索引
MySQL 只有在能利用索引直接获取去重结果时，才能跳过临时表。例如：
- 查询
SELECT DISTINCT city FROM users;，应在city字段建单列索引（INDEX(city)）； - 若查
SELECT DISTINCT dept, city FROM users;，需联合索引INDEX(dept, city)，且顺序与 SELECT 中字段一致； - 避免在索引前导列上使用函数或隐式类型转换（如
DISTINCT UPPER(name)），否则索引失效。
用 GROUP BY 替代 DISTINCT（必要时加 LIMIT）
在某些版本（尤其是 MySQL 5.7+）中，GROUP BY 在有索引支持时可能比 DISTINCT 更易触发松散索引扫描（Loose Index Scan）。例如：
SELECT DISTINCT city FROM locations WHERE status = 1;- 可尝试改写为：
SELECT city FROM locations WHERE status = 1 GROUP BY city;，并确保索引为INDEX(status, city)； - 如果只需前 N 个去重结果，务必加上
LIMIT（如LIMIT 100），避免全量扫描。
避免 SELECT * 配合 DISTINCT
DISTINCT 是对整行去重，若写成 SELECT DISTINCT * FROM t，MySQL 必须读取所有字段并逐行比较，极大增加 I/O 和内存开销。
- 只选择真正需要去重的字段，例如
SELECT DISTINCT user_id, category； - 若业务上需关联其他字段（如最新时间），改用
GROUP BY + 聚合函数（如MAX(created_at)），而非先 DISTINCT 再 JOIN； - 确认是否真的需要“去重”——有时是业务逻辑重复，可通过应用层或唯一约束提前规避。
检查执行计划，识别隐式排序与临时表
运行 EXPLAIN SELECT DISTINCT ...，重点关注：
- type=ALL 或 rows 值过大 → 缺少有效索引；
- Extra 中出现 Using temporary; Using filesort → 强制走临时表，必须优化；
- key 为空或未命中预期索引 → 检查字段顺序、NULL 值处理、字符集是否一致（如 utf8mb4 vs utf8）。
