必须用临时表绕开ERROR 1093，因MySQL禁止在DELETE/UPDATE子查询中直接引用目标表；临时表将读写分离为两阶段，先查出需保留ID再安全操作原表。
为什么必须用临时表绕开 ERROR 1093
MySQL 不允许在 DELETE 或 UPDATE 的子查询中直接引用目标表，否则报错：ERROR 1093 (HY000): You can't specify target table 't' for update in FROM clause。这不是语法缺陷，而是引擎为防止读写冲突做的硬性限制。临时表把“读”和“写”彻底拆成两个阶段：先稳稳查出要留的 ID，再安全删/写原表。
CREATE TEMPORARY TABLE LIKE vs AS SELECT DISTINCT
两种建临时表方式效果不同，选错会丢索引或主键属性：
-
CREATE TEMPORARY TABLE tmp LIKE users：完整复制原表结构，包括PRIMARY KEY、AUTO_INCREMENT、索引——推荐用于后续要INSERT INTO users SELECT *的场景 -
CREATE TEMPORARY TABLE tmp AS SELECT DISTINCT * FROM users：只复制字段和数据类型，不带索引、主键、自增——适合纯中间计算，比如只用来GROUP_CONCAT
如果原表有复合唯一约束（如 (email, phone)），DISTINCT * 能正确去重；但若只想按某几列判重，就得显式 GROUP BY + 聚合函数，不能依赖 DISTINCT。
INSERT INTO 前必须处理 NULL 分组陷阱
当去重依据字段（如 email）允许为 NULL，GROUP BY email 会把所有 NULL 归为一组，导致只保留其中一条、其余全删。必须显式隔离 NULL：
- 用
GROUP BY IFNULL(email, CONCAT('null-', id))把每个NULL变成唯一伪值 - 或分两步：先处理非空行，再单独
INSERT ... WHERE email IS NULL LIMIT 1
另外，NOT IN (SELECT id FROM tmp) 遇到 tmp.id 含 NULL 会整体失效——务必确保临时表里没有 NULL 主键值，必要时加 WHERE id IS NOT NULL 过滤。
大表操作前必须加索引和避开高峰期
临时表默认无索引，但后续 DELETE ... NOT IN (SELECT id FROM tmp) 或 JOIN 时，没索引会让查询从 O(n) 退化成 O(n²)。执行完 CREATE TEMPORARY TABLE 后立刻加索引：
ALTER TABLE tmp_keep ADD INDEX idx_id (id);
还有三个硬性提醒：
- 连接池环境下，整个流程（建表 → 插入 → 删原表 → 写回）必须在同一个数据库连接内完成，否则临时表不可见
- 千万级以上数据量，
TRUNCATE TABLE虽快但会锁表；可改用DELETE FROM users WHERE id NOT IN (...)分批删（每次 1 万行） - 原表若有外键被其他表引用，
TRUNCATE会失败；此时只能用DELETE+INSERT IGNORE或先禁用外键检查（SET FOREIGN_KEY_CHECKS = 0）
真正麻烦的从来不是 SQL 写法，而是 NULL 处理、索引缺失、连接生命周期这三处——漏掉任意一个，线上跑起来就卡死或丢数据。
