不能直接用 DISTINCT 或 GROUP BY 清理无主键表重复行，因二者无法定位并删除原始行，且 MySQL 禁止在 DELETE 中子查询同一表，易触发 ERROR 1093；无主键时 ROW_NUMBER() 也受限，稳妥方案是用 CREATE TABLE ... SELECT 去重后替换原表。
为什么不能直接用 DISTINCT 或 GROUP BY 清理无主键表的重复行
因为没有主键（或唯一标识列），DISTINCT 只能去重结果集，无法定位并删除原始重复行；GROUP BY 同样不提供行级操作能力。更关键的是：MySQL 在 DELETE ... JOIN 或子查询中对无主键表的处理容易触发“You can't specify target table for update in FROM clause”错误，尤其在 5.7+ 默认 SQL 模式下。
常见错误现象：ERROR 1093 (HY000): You can't specify target table 't' for update in FROM clause
- 根本原因：MySQL 不允许在同一个语句中，既从某张表查数据，又删这张表（哪怕逻辑上是不同别名）
- 即使加了
AS别名或嵌套子查询，只要最终指向同一张物理表，就可能报错 - 无主键时，连用
ROW_NUMBER()窗口函数也受限——MySQL 8.0 才支持，且需确保排序列能稳定区分“应保留哪一行”，否则去重结果不可控
用临时表 + CREATE TABLE ... SELECT 安全去重（兼容 5.6+）
这是最稳妥、跨版本兼容的做法：把去重后的数据导出到新表，再原子替换原表。不需要主键，也不依赖窗口函数。
实操步骤：
- 确认重复判断依据：比如整行重复，或指定若干列（如
name, email, created_at）组合重复 - 用
GROUP BY+MIN(id)（假设有自增id）或MAX(id)选保留行——但注意：若真无任何唯一列，需先加一列ALTER TABLE t ADD COLUMN _row_id INT AUTO_INCREMENT FIRST, ADD PRIMARY KEY (_row_id)，否则无法可靠选“第一行” - 执行创建去重表：
CREATE TABLE t_dedup AS SELECT MIN(id) AS id, name, email, created_at FROM t GROUP BY name, email, created_at;
- 删原表、重命名：
DROP TABLE t; ALTER TABLE t_dedup RENAME TO t;
⚠️ 注意：如果原表有索引、外键、触发器，需手动重建；CREATE TABLE ... SELECT 不复制表结构元信息（如注释、字符集、存储引擎），建议先用 SHOW CREATE TABLE t 记录建表语句，再按需调整新表。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
用 DELETE JOIN 原地清理（仅限 MySQL 8.0+ 且有隐式唯一列）
如果有自增 id 或时间戳列可作为“保留依据”，可用 JOIN 自关联删除。但必须绕过 MySQL 的目标表限制。
- 核心技巧：把子查询包装成派生表（即多一层
SELECT * FROM ( ... ) AS tmp），让优化器认为是“不同表” - 示例（保留每组最小
id的行，删其余）：DELETE t1 FROM t AS t1 INNER JOIN t AS t2 WHERE t1.name = t2.name AND t1.email = t2.email AND t1.created_at = t2.created_at AND t1.id > t2.id;
- 更安全写法（显式规避 ERROR 1093）：
DELETE FROM t WHERE id NOT IN ( SELECT id FROM ( SELECT MIN(id) AS id FROM t GROUP BY name, email, created_at ) AS keep );
⚠️ 性能提示：该操作在大表上会锁表、产生大量 binlog；务必在低峰期执行，并确保 (name, email, created_at) 有联合索引，否则 GROUP BY 和 JOIN 会全表扫描。
无任何候选键时的现实妥协方案
如果表真的一列都不能用来定义“重复”（比如只有文本描述列，且内容高度相似但不完全相等），那就不是数据库层能解决的问题——这已属于模糊去重或 NLP 范畴。
- 不要强行用
MD5(text_col)或SUBSTRING(text_col, 1, 200)做哈希去重，哈希碰撞或截断会导致误删 - 优先检查业务逻辑：是否本该有主键？能否补加
ALTER TABLE t ADD COLUMN uuid CHAR(36) DEFAULT (UUID());并设为主键？ - 若必须人工核对，导出后用 Python/Pandas 做余弦相似度或 difflib 匹配，再生成待删 ID 列表，回库执行
DELETE FROM t WHERE id IN (...)
真正难的从来不是语法，而是明确“哪些算重复”——这个定义权不在 SQL 手里，在业务规则和数据质量治理流程里。
