delete慢主因是where条件列未建索引，导致全表扫描；应通过explain分析执行计划，为等值+范围条件创建复合索引，避免对text/json直接建索引，且需分批删除防锁表。
WHERE 条件没走索引，DELETE 就是全表扫描
mysql 或 postgresql 里 DELETE FROM table WHERE xxx 慢，大概率不是语句本身的问题，而是 WHERE 条件列没建索引。比如按 status 删除旧数据，但 status 列没索引，引擎就得一行行读全表判断——哪怕只删 10 行，也要扫 100 万行。
实操建议：
- 用
EXPLAIN DELETE ...（MySQL）或EXPLAIN (ANALYZE) DELETE ...（PostgreSQL）看执行计划，确认是否用了索引扫描（index scan或range），而不是seq scan - 对高频删除条件列加索引，例如
CREATE INDEX idx_status_created ON orders (status, created_at)；复合索引注意顺序，等值条件在前，范围条件在后 - 别给
TEXT、JSON列直接建普通索引——MySQL 8.0+ 可用函数索引，如CREATE INDEX idx_json_type ON events ((json_unquote(json_extract(data, '$.type'))))
一次删太多会锁表、卡主库、触发 binlog 膨胀
想删 50 万行，写一条 DELETE FROM logs WHERE ts ，MySQL 可能锁住整个表几秒甚至几分钟，同时生成巨量 binlog，主从延迟飙升，还可能触发 <code>max_allowed_packet 错误。
实操建议：
- 分批删，每批控制在 1k–10k 行，用主键或自增 ID 做游标：
DELETE FROM logs WHERE id ，循环推进 - 避免用
LIMIT配合无索引排序（如ORDER BY created_at LIMIT 1000），这会导致每次都要重排；优先用带索引的字段做边界，比如WHERE id > last_id AND ts - PostgreSQL 注意
DELETE ... LIMIT不合法，得用 CTE 或子查询模拟：WITH cte AS (select id FROM logs WHERE ts
TRUNCATE 比 DELETE 快得多，但不能带条件
TRUNCATE TABLE 是 DDL 操作，不走事务、不记逐行 binlog、不触发触发器，清空整表只要毫秒级。但它不能加 WHERE，也不能回滚（MySQL InnoDB 里其实支持事务内 TRUNCATE，但多数人不敢赌）。
实操建议：
- 确定要清空全部数据时，优先用
TRUNCATE TABLE，比DELETE FROM table快一个数量级 - 如果只是“保留最新 N 天”，又不想写复杂分批逻辑，可考虑分区表：按天/月分区后，直接
ALTER TABLE logs DROP PARTITION p2022_12，秒删百万级数据 - 注意权限差异：
TRUNCATE需要DROP权限，而DELETE只需DELETE权限；线上账号若没DROP权，就只能老实用DELETE
外键和触发器会让 DELETE 慢出意料
一张订单表 orders 有外键关联到 order_items，你删一条订单，数据库默认要检查并级联删所有子记录——如果没在 order_items(order_id) 上建索引，那删一条订单可能触发对子表的全扫描。
实操建议：
- 所有外键列必须建索引，否则关联操作就是灾难；用
SHOW CREATE TABLE检查外键定义，再用SHOW INDEX确认对应列有索引 - 禁用触发器临时提速？别轻易试。MySQL 的
SET SQL_SAFE_UPDATES=0不影响触发器，PostgreSQL 也没有全局关触发器的开关；真要绕过，得先DROP TRIGGER，删完再重建，风险极高 - 如果业务允许，把级联逻辑提到应用层：先
SELECT id FROM order_items WHERE order_id = ?拿到子 ID 列表，再批量DELETE FROM order_items WHERE id IN (...)，反而更可控
真正卡住批量 DELETE 的，往往不是语法或配置，而是索引缺失 + 分批策略粗糙 + 外键没索引这三件事叠在一起。调优前先看执行计划，别猜。