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）。
