DISTINCT仅去重查询结果，不能删除重复行；真正删重需用GROUP BY配合DELETE或临时表，如CREATE TABLE logs_clean LIKE logs; INSERT INTO logs_clean SELECT * FROM logs GROUP BY event_date; RENAME TABLE。
直接说结论：DISTINCT 不能真正“处理”日期重复数据，它只影响查询结果；真正删重必须用 GROUP BY 配合 DELETE 或临时表。别指望 DISTINCT 能改表结构或删行。
为什么 DISTINCT 对去重没用（但常被误用）
很多人看到日期字段重复，第一反应是写 SELECT DISTINCT date_col FROM table —— 这确实能返回不重复的日期值，但它只是“查出来不重复”，原表一条没少，索引、存储、后续统计全不受影响。
常见错误现象：
- 用
DISTINCT查完以为“已去重”，结果导出报表还是多条同日期记录 - 在含其他字段的查询里加
DISTINCT date_col, name，结果发现name不同导致根本没去成 - 误以为
DISTINCT能配合DELETE用，比如DELETE DISTINCT ...—— MySQL 不支持这种语法
GROUP BY 是删重的核心，但必须配聚合函数和子查询
真正删日期重复数据，关键是定义“保留哪一条”。最常用的是按日期分组，留 MIN(id) 或 MAX(id) 对应的那行。
例如，表 logs 有 id（自增主键）、event_date、content，想按 event_date 去重，留最早那条：
DELETE FROM logs WHERE id NOT IN (
SELECT min_id FROM (
SELECT MIN(id) AS min_id FROM logs GROUP BY event_date
) AS t
);
注意点：
- 外层再套一层
SELECT是必须的，否则 MySQL 报错You can't specify target table for update in FROM clause - 如果表很大（比如超百万行），这条语句会锁表、慢、甚至 OOM；生产环境慎用
- 若没有
id这类数值型主键，得先加自增列或用临时表方案
大数据量时，用临时表比直接 DELETE 更稳
当 logs 表有几千万行，且重复率高，上面的 DELETE 可能跑几个小时还失败。这时推荐倒腾法：
CREATE TABLE logs_clean LIKE logs; INSERT INTO logs_clean SELECT * FROM logs GROUP BY event_date; RENAME TABLE logs TO logs_bak, logs_clean TO logs;
这个流程的关键细节：
-
GROUP BY event_date在无明确排序时，MySQL 默认取每组第一条（引擎相关），不保证是MIN(id)；如需确定性，必须显式用MIN()或窗口函数 - 执行前务必
CREATE INDEX idx_event_date ON logs(event_date)，否则GROUP BY极慢 - 替换表名后，记得检查外键、触发器、权限是否同步，否则应用可能报错
日期去重最容易被忽略的坑
日期字段本身容易藏坑：比如 DATETIME 带时分秒，表面看是同一天，实际值不同；又比如 DATE 类型但存了 '0000-00-00' 这种非法值，GROUP BY 会把它们全归为一组。
操作前一定要确认：
- 用
SELECT event_date, COUNT(*) FROM logs GROUP BY event_date ORDER BY COUNT(*) DESC LIMIT 5看看真实重复分布 - 检查是否有空值或非法日期：
SELECT * FROM logs WHERE event_date IS NULL OR event_date = '0000-00-00' - 如果业务上“同一天”就该算重复，但字段是
DATETIME，得先转成DATE(event_date)再分组
