无主键表的DELETE会退化成全表扫描，因缺乏索引导致逐行判断和全表加锁；隐式ROW_ID不可用，分批删除失效；主从延迟加剧且难恢复；补救仅靠加主键或分区清理。
无主键表的DELETE会退化成全表扫描
MySQL 的 DELETE 语句在执行时，如果 WHERE 条件无法命中索引，就会走全表扫描 + 逐行判断。无主键表通常也缺乏有效二级索引，导致每次删除都要读取并锁住整张表的所有数据页。更糟的是，InnoDB 在没有聚簇索引（即无主键）时，会用隐式 ROW_ID 作为聚簇索引，但这个字段不可见、不可查询、不可用于 WHERE，所以你根本没法靠它做范围控制。
主从延迟可能卡死且无法恢复
主库执行一条对无主键表的大批量 DELETE，binlog 记录的是“逻辑删除行为”，从库回放时必须重演整个扫描过程——它得把全表所有行都读一遍，再逐个比对条件。这会导致：
- 从库 SQL Thread 长时间卡在单条语句上，
Seconds_Behind_Master持续上涨，Exec_Master_Log_Pos却几乎不动 - 即使主库早就执行完，从库也无法并发应用后续 binlog（因为依赖顺序）
- 若该表还同时被其他写入频繁访问，从库可能因 buffer pool 压力过大而 OOM 或夯住
分批删除策略在无主键表上基本失效
常规推荐的“WHERE id > last_id ORDER BY id LIMIT N”或“WHERE id BETWEEN x AND y”都依赖主键或有索引的列来快速定位边界。无主键表没有这样的列，你无法安全地切分数据块：
-
LIMIT不可控：ORDER BY无索引字段 → 触发 filesort，性能断崖下跌；LIMIT只限制返回行数，不保证跳过已处理行 -
OFFSET更危险：每轮都要跳过前 N 行，越往后越慢，I/O 和 CPU 开销指数级上升 - 用
SELECT ... INTO OUTFILE+ 重建表？风险高：中间状态不可控，且业务写入需全程停写
真正能落地的补救路径只有两条
不是“怎么删更好”，而是“怎么绕开删”：
- 立即加主键：
ALTER TABLE tbl ADD PRIMARY KEY (id);—— 前提是存在一个非空唯一列；若没有，先加自增列再设主键，但要注意业务是否允许 ID 变更 - 改用分区清理：
ALTER TABLE tbl DROP PARTITION p_old;—— 如果表已按时间分区，这是唯一秒级、无锁、不扫表的方案
别低估隐式 ROW_ID 的破坏力：它不递增、不连续、不可预测，连 SELECT MIN(ROW_ID) 都非法。所谓“按 ROW_ID 分批”，在 MySQL 里根本不可行。
