delete语句必须带where条件，否则会清空整表；实操需先select确认、禁用自动提交、避免类型不匹配导致全表扫描、合理建索引、分批处理大数据量、勿依赖auto_increment连续性、谨慎使用外键级联删除。
DELETE 语句必须带 WHERE，否则整表清空
MySQL 的 DELETE 默认不加条件就是删全表，不是删一行。没写 WHERE 或者 WHERE 条件恒真（比如 WHERE 1），执行后 SELECT COUNT(*) 就是 0 —— 这不是 bug，是设计如此。
实操建议：
- 写完
DELETE FROM table_name WHERE ...后，先用对应SELECT * FROM table_name WHERE ...确认要删的是哪些行 - 开发/测试环境务必开启
AUTOCOMMIT=OFF，删之前手动BEGIN，确认无误再COMMIT；误删还能ROLLBACK - 生产环境禁止直接在命令行或 Navicat 里手敲
DELETE，应走预审 SQL 脚本或运维平台
WHERE 条件里字段类型不匹配会导致全表扫描
比如 id 是 INT 类型，但写了 WHERE id = '123'（字符串），MySQL 会隐式转换，索引失效，删得慢还锁表久。
常见错误现象：
- 执行
DELETE卡住几秒甚至几十秒，SHOW PROCESSLIST显示Updating状态 -
EXPLAIN FORMAT=TRADITIONAL DELETE FROM t WHERE id = '123'显示type: ALL（全表扫描）
实操建议：
- WHERE 中的值类型必须和字段定义一致：
INT字段就用数字，VARCHAR字段才用引号字符串 - 对
WHERE条件字段建索引（尤其是高频率删除的字段），但别在大文本字段（如TEXT）上建普通索引 - 批量删多行时，避免用
IN (1,2,3,...1000)，超过几百个值优先考虑分批或用临时表 JOIN
自增主键不会重用，删完再插会跳号
MySQL 的 AUTO_INCREMENT 计数器只增不减。哪怕你删了 id=5 那行，下一条 INSERT 还是用下一个最大值（比如当前最大是 10，就插 11），不会回填 5。
这不算问题，但容易被误解为“数据没删干净”或“主键异常”。真实影响只有：
- 主键值越来越稀疏，对某些依赖连续 ID 的业务逻辑（比如分页推算、前端硬编码）有干扰
- 如果用
MAX(id)做统计或分片依据，结果可能不准
实操建议：
- 不要为“回收 ID”去
ALTER TABLE ... AUTO_INCREMENT = N，除非明确知道后果（并发插入可能冲突） - 需要连续编号的场景，改用单独的业务序列号字段，别依赖
AUTO_INCREMENT
外键约束会让 DELETE 失败或级联删错数据
如果表 A 的某字段是外键，指向表 B 的主键，那么默认情况下：删表 B 的某行，若表 A 里还有引用它，就会报错 Cannot delete or update a parent row: a foreign key constraint fails。
但如果你建表时设了 ON DELETE CASCADE，删父表一行，子表相关行会自动跟着删 —— 这很危险，尤其没意识到存在级联关系时。
实操建议：
- 删之前查外键定义：
SELECT CONSTRAINT_NAME, UPDATE_RULE, DELETE_RULE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'your_table' AND REFERENCED_TABLE_NAME IS NOT NULL - 线上表尽量用
ON DELETE RESTRICT（默认），而不是CASCADE；真要级联，应在应用层显式控制 - 跨库或跨服务的关联，数据库层无法建外键，更得靠应用逻辑兜底
真正难的不是写对那条 DELETE，而是判断「这一行该不该删」「删了之后谁会崩」—— 日志、监控、上下游依赖，比语法重要得多。
