云数据库执行DELETE会触发限流，因其易引发全表扫描、大量行锁及Binlog激增，导致QPS/IO/CPU超限；需分批删除并配合SLEEP、独立事务、行数监控等措施规避。
为什么云数据库执行 DELETE 会触发限流？
云数据库（如阿里云 RDS、腾讯云 CDB、AWS RDS）底层会对高负载操作做主动干预，DELETE 尤其是无 WHERE 条件或范围过大的语句，容易被识别为“全表扫描 + 大量行锁 + Binlog 写入激增”，从而触发 QPS/IO/CPU 限流策略。典型表现是命令卡住、返回超时、或直接报错 Too many rows affected、Throttling by system 等提示。
这不是 SQL 写错了，而是云厂商的资源保护机制——它不关心你逻辑是否正确，只看操作对共享实例的影响。
- 单次
DELETE FROM t WHERE create_time 扫描百万行，很可能被限流； - 即使加了索引，若
WHERE条件选择性差（如status = 0占 95% 行），仍可能触发慢查询熔断； - Binlog 格式为
ROW时，每删一行都写一条日志，IO 压力翻倍，比STATEMENT更易被限。
怎么安全分批删除？用 LIMIT 还是游标？
别用 DELETE ... LIMIT N 直接循环——在高并发或有新数据写入的场景下，可能漏删、重复删，或因 ORDER BY 缺失导致非确定性行为。
推荐用「主键游标」方式：每次取最小 ID 范围，删完再推进偏移。前提是表有自增主键或唯一递增字段（如 id 或带索引的 create_time）。
DELETE FROM orders WHERE id BETWEEN ? AND ? AND create_time < '2022-01-01';
- 先查边界：
SELECT MIN(id), MAX(id) FROM orders WHERE create_time - 按每 5000 行切块（具体值依实例规格调，RDS MySQL 8.0 一般 ≤10000 安全）；
- 每次执行前加
SELECT COUNT(*)验证待删数量，避免误删整表； - 务必在
WHERE中同时带上时间条件和主键范围，防止因数据变更导致逻辑错位。
云平台特有的限流开关与配置项有哪些？
不同厂商暴露的控制粒度不同，但关键配置基本都可通过控制台或 API 调整：
- 阿里云 RDS：开启「SQL 审计」后可在
slow_log查到被限流的DELETE，并设置max_execution_time（单位毫秒）限制单条语句最长运行时间； - 腾讯云 CDB：提供「长事务阻断」开关，可设阈值（如 >60s）自动 Kill，需配合应用层重试逻辑；
- AWS RDS：通过 Performance Insights 观察
db.load和db.sql.queries指标，结合wait/io/table/sql/handler判断是否卡在锁等待； - 通用规避项：
SET SESSION innodb_lock_wait_timeout = 3;（降低锁等待时间，避免堆积）；SET SESSION binlog_format = 'STATEMENT';（仅限确定安全场景，如无函数/临时表）。
分批脚本里最容易忽略的三个细节
写个 while 循环不难，但生产环境出问题往往卡在这几个点：
- 没加
SLEEP(0.1)：连续高频提交会快速触达 QPS 上限，哪怕每次只删 100 行，也要留出网络和 IO 缓冲间隙； - 忽略事务大小：InnoDB 默认
innodb_log_file_size有限，单事务删超 5w 行可能引发log sequence number overflow，建议每批独立COMMIT； - 没监控影响行数：用
SELECT ROW_COUNT()检查实际删除数，若返回 0 说明已删完或条件失效，必须退出循环，否则变成死循环。
云数据库的限流不是故障，是常态。真正麻烦的不是“怎么删”，而是“删的时候系统还在写、还在备份、还在同步从库”。所有分批逻辑必须默认假设数据在动，不能依赖静态快照。
