delete不加where会清空整表，mysql无确认和回收机制；应先用select count(*)验证、走审批流程、开启事务并人工审核；推荐标记删除而非物理删除；limit仅限部分场景使用。
DELETE 语句不加 WHERE 就是删全表
这是最常踩的坑：执行 DELETE FROM users; 而没加 WHERE，结果整张表数据清空。MySQL 不会二次确认，也不会进回收站——删了就是删了。
真实场景中，开发连测试库都可能误操作，尤其在脚本里拼接 SQL 时，WHERE 条件变量为空却没校验，直接变成无条件删除。
- 上线前务必检查所有
DELETE是否带有效WHERE，建议用SELECT COUNT(*)先查一遍要删多少行 - 生产环境禁止直接执行
DELETE，应走审批 + 人工审核 SQL + 开启事务（先BEGIN，删完SELECT验证，再COMMIT或ROLLBACK） - 某些运维规范会禁用
DELETE，改用标记删除（如加is_deleted TINYINT字段），避免物理删除风险
想限制删除条数？只能用 LIMIT，但有严格限制
MySQL 支持 DELETE ... LIMIT N，比如 DELETE FROM logs WHERE created_at 。但它只在单表删除中生效；多表 <code>DELETE（如 DELETE t1 FROM t1 JOIN t2 ON ...）不支持 LIMIT，会报错 You can't specify target table for update in FROM clause 这类提示。
-
LIMIT是 MySQL 特有语法，标准 SQL 不支持，迁移到 PostgreSQL 或 Oracle 时需重写逻辑 - 使用
LIMIT时，MySQL 仍会扫描满足WHERE的全部行，只是最后只删前 N 条——如果条件匹配百万行，性能依然差 - 高并发下，
LIMIT不保证“删的是哪 N 条”，因为没有显式ORDER BY，底层顺序取决于索引遍历路径，结果不可预测
DELETE 和 TRUNCATE 的关键区别不止是速度
很多人以为 TRUNCATE TABLE users; 只是更快的 DELETE，其实它根本不是 DML，而是 DDL 操作：会重置自增 ID、释放磁盘空间、绕过事务日志（不写 binlog 的 row 格式下可能不被复制）、且不能回滚（即使在事务中执行也会隐式提交）。
- 如果表有外键引用，
TRUNCATE直接失败，而DELETE可以正常删（只要没开启级联约束） -
TRUNCATE不触发DELETE触发器，DELETE会——这点常被忽略，导致业务逻辑漏执行 - 权限上，
TRUNCATE需要DROP权限，而DELETE只需要DELETE权限
WHERE 条件字段没索引？DELETE 可能锁表锁到超时
例如执行 DELETE FROM orders WHERE status = 'pending' AND updated_at ，如果 <code>status 或 updated_at 没单独/联合索引，MySQL 得全表扫描，期间对每行加行锁（InnoDB），实际效果接近锁整张表，其他查询/更新全被阻塞。
- 用
EXPLAIN看DELETE对应的SELECT是否走了索引（比如EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND updated_at ） - 批量删除老数据，优先按主键或自增 ID 分页删，比如先删
id BETWEEN 1 AND 10000，再删下一批，避免单次扫描过大范围 - 线上大表删数据，别用单条
DELETE，考虑归档后DROP PARTITION（如果用了分区）或用 pt-archiver 工具做限流删除
真正难的不是语法，是删之前得知道这行数据被谁依赖、锁多久、binlog 怎么记、从库会不会延迟——这些不会报错，但会让系统在某个凌晨突然卡住。
