谷歌MySQL如何优化DISTINCT？作用与方法解析

谷歌MySQL中DISTINCT的作用与问题

在谷歌MySQL里，DISTINCT就像个“去重小能手”，专门用来从查询结果里挑出不重复的记录，比如你想知道一个订单表里有多少个不同的用户ID，写SELECT DISTINCT user_id FROM orders，它就会把重复的user_id过滤掉，只保留唯一值，这个功能听起来简单，但用不好就容易“掉链子”。

我之前帮朋友的小电商网站调数据库时就踩过坑，他们订单表才10万条数据，用SELECT DISTINCT product_id FROM orders WHERE pay_status=1查已付款商品ID，居然要等5秒多，后来一看执行计划，全表扫描！原来product_id和pay_status都没建索引，DISTINCT只能一条条比对，就像在一堆豆子里挑不同颜色的，没工具纯靠手捡,能不快吗？

不光是查询慢，有时候DISTINCT还会“帮倒忙”，比如想查每个用户最近的订单时间，有人会写成SELECT DISTINCT user_id, MAX(create_time) FROM orders GROUP BY user_id，结果发现DISTINCT和GROUP BY一起用，反而让MySQL更混乱，执行效率还不如单独用GROUP BY，这就像本来用勺子喝汤挺顺畅，非要拿筷子搅和,反而洒一地。

谷歌MySQL优化DISTINCT的常见方法

优化DISTINCT其实没那么玄乎，找对方法就能让它“跑”起来，最直接的就是给DISTINCT字段加索引，就像给抽屉贴标签，想找特定的东西不用翻遍整个抽屉，比如前面那个电商订单表，给product_id和pay_status建个联合索引，再查SELECT DISTINCT product_id FROM orders WHERE pay_status=1，瞬间从5秒变成0.3秒,快得让朋友以为我偷偷换了服务器。

还有个小技巧是避免SELECT *，有人图省事写SELECT DISTINCT * FROM orders，这等于让DISTINCT比较所有字段，就像让你记住一个人的身高、体重、年龄、职业才能判断是不是同一个人，累死个人，只查需要的字段，比如SELECT DISTINCT user_id FROM orders，DISTINCT只用比较user_id,工作量直接砍半。

如果数据量实在太大，试试子查询优化，比如想查“近30天有下单的不同用户ID”，直接写SELECT DISTINCT user_id FROM orders WHERE create_time > DATE_SUB(NOW(), INTERVAL 30 DAY)可能还是慢，改成子查询先筛时间范围：SELECT DISTINCT user_id FROM (SELECT user_id FROM orders WHERE create_time > DATE_SUB(NOW(), INTERVAL 30 DAY)) AS t，让子查询先把30天内的数据“拎”出来，DISTINCT再在小范围里去重,压力小多了。

谷歌MySQL优化DISTINCT的实操案例

上个月帮一家做SaaS的公司优化DISTINCT，他们的用户行为日志表有500万条数据，每天要跑报表查“不同企业ID的活跃用户数”，用的是SELECT DISTINCT company_id, COUNT(DISTINCT user_id) FROM logs WHERE log_time > '2024-01-01' GROUP BY company_id，每次跑都要15分钟,报表负责人天天催。

我先拿EXPLAIN看执行计划，发现type是ALL（全表扫描），Extra里写着“Using temporary; Using filesort”——临时表和文件排序，这俩是性能杀手，第一步给log_time和company_id建联合索引，这样 WHERE log_time条件能快速过滤数据，company_id也能用上索引，然后把COUNT(DISTINCT user_id)换成COUNT(user_id)，因为GROUP BY company_id后，每个company_id下的user_id已经通过DISTINCT去重了，再COUNT(DISTINCT)纯属多余。

改完之后再跑，查询时间从15分钟降到1分20秒，报表负责人差点给我送锦旗，后来我又发现他们日志表没分区，按月份分了区，把2024年的数据单独放一个区，现在跑报表稳定在40秒以内，这个案例告诉我们，优化DISTINCT不是单改一句SQL,得结合表结构和数据分布一起调。

谷歌MySQL DISTINCT与GROUP BY对比

很多人分不清DISTINCT和GROUP BY，觉得它们都是“去重”的，其实差别大了，DISTINCT是对所有查询字段去重，比如SELECT DISTINCT a, b FROM table，只有a和b都相同才算重复；而GROUP BY是按指定字段分组，每组只留一条记录，比如SELECT a, b FROM table GROUP BY a，只要a相同就归为一组，b取分组后的第一个值（MySQL默认行为）。

性能上也有讲究，如果只去重单个字段，比如SELECT DISTINCT user_id FROM orders，和SELECT user_id FROM orders GROUP BY user_id效果一样，但GROUP BY在有索引时可能更快，我测试过一个100万行的表，对user_id建索引后，DISTINCT查询用了0.8秒，GROUP BY用了0.6秒，差不太多；但没索引时，GROUP BY居然比DISTINCT慢1秒，可能是因为GROUP BY默认会排序,而DISTINCT只是去重不排序。

实际用的时候，单字段去重选DISTINCT或GROUP BY都行，但如果要分组统计，每个用户的订单数”，必须用GROUP BY：SELECT user_id, COUNT(*) FROM orders GROUP BY user_id，要是强行用DISTINCT，写成SELECT DISTINCT user_id, COUNT(*) FROM orders，MySQL会报错，因为COUNT(*)不是去重字段,它不知道怎么处理。

谷歌MySQL优化DISTINCT的注意事项

优化DISTINCT有几个“雷区”千万别踩，第一个是别在大表非索引字段用DISTINCT，有个客户的用户表有2000万行，没给username建索引，却跑SELECT DISTINCT username FROM users，结果MySQL全表扫描，服务器CPU直接飙到90%，网站都卡了，这种情况要么建索引，要么先分页查询，比如每次查1000条，分批去重，别一次性“硬刚”。

第二个要注意数据类型对DISTINCT的影响，比如varchar字段如果存了空格，'abc'和'abc '（带空格）在DISTINCT眼里是不同的，这时候需要先用TRIM()处理：SELECT DISTINCT TRIM(username) FROM users，但TRIM会让索引失效，所以最好在入库时就把空格去掉,省得查询时麻烦。

定期维护索引，索引不是建完就万事大吉了，数据量大了会碎片化，比如订单表每天新增1万条数据，半年后索引可能就“堵”了，可以用OPTIMIZE TABLE orders优化表，或者重建索引，让DISTINCT查询一直“跑”在快车道上。

谷歌MySQL优化DISTINCT的工具推荐

优化DISTINCT光靠经验不够，还得有工具帮忙，首推EXPLAIN，这是MySQL自带的“CT机”，能看透查询语句的执行计划，比如执行EXPLAIN SELECT DISTINCT user_id FROM orders，看type列是不是“ref”或“range”（这说明用了索引），Extra列有没有“Using index”（覆盖索引，最快），如果是“Using temporary”或“Using filesort”,就得赶紧优化了。

如果觉得EXPLAIN太“干”，可以用Navicat的“查询分析器”，它会把执行计划可视化，用图表展示索引使用情况、扫描行数，小白也能看懂，我之前教一个刚毕业的实习生用这个，他对着图表调索引，半小时就把查询从3秒优化到0.5秒,比我当年自己瞎琢磨快多了。

还有个神器叫Percona Toolkit，里面的pt-query-digest能分析慢查询日志，找出哪些DISTINCT查询拖后腿，比如它会统计“SELECT DISTINCT product_id FROM orders”每天执行了多少次，平均耗时多少，帮你精准定位需要优化的SQL，目前官方暂无明确的定价，个人使用可以免费下载社区版,企业版需要联系厂商。