Amazon Aurora Serverless单条主键记录删除执行时间过长求助

问题回顾 #

在20亿条记录规模的cc_list表中执行主键匹配的单条删除：

DELETE FROM cc_list WHERE id = '1904746137';

EXPLAIN输出显示类型为Range，虽命中主键索引，但执行时间超900秒且频繁出现锁等待超时，已确认主键索引、检查锁与长事务、监控性能负载并在低峰期操作，数据库内存为196GB。

原因分析 #

• 主键数据类型隐式转换：EXPLAIN显示Type: Range而非预期的const，说明实际未执行精准主键点查询。若id字段定义为数字类型（BIGINT/INT），而查询中使用字符串值（带引号），会触发隐式类型转换，导致数据库对主键索引做全范围扫描而非直接定位单条记录，20亿条记录的索引扫描必然耗时极长。
• 大规模表的索引维护开销：InnoDB引擎下，删除操作需维护聚簇索引结构，同时更新所有二级索引（若存在）。20亿条记录的表即使单条删除，也会因数据页的碎片整理、元数据同步等操作产生远高于小表的IO和CPU开销。
• Aurora Serverless资源限制：Serverless模式下，ACU（Aurora容量单元）可能处于较低档位，CPU或IO吞吐量不足以支撑大规模表的元数据操作，即使内存充足，IO瓶颈仍会导致延迟。
• 分布式锁同步延迟：Aurora多AZ复制架构下，删除操作的锁状态需在主从节点同步，若集群状态不稳定或复制延迟，会增加锁等待时间。

解决建议 #

• 修正查询的类型匹配：先查询cc_list表的id字段类型，若为数字类型，将删除语句改为无引号的数字值：

  DELETE FROM cc_list WHERE id = 1904746137;
  

  确保执行精准主键点查询，避免隐式转换导致的全索引扫描。
• 缩小事务范围：将删除操作放在极简事务中执行，减少锁持有时间：

  START TRANSACTION;
  DELETE FROM cc_list WHERE id = 1904746137;
  COMMIT;
  

• 优化索引与表结构：删除不必要的二级索引，减少删除时的索引维护开销；在业务低峰期执行OPTIMIZE TABLE cc_list;整理表碎片（注意该操作会锁表）。
• 调整Serverless资源配置：临时提高最小ACU值，确保有足够的CPU和IO资源支撑操作；或临时切换到Provisioned模式完成删除后再切回Serverless。
• 排查锁与InnoDB状态：执行SHOW ENGINE INNODB STATUS;查看锁等待详情，确认是否存在未提交事务持有锁；将innodb_buffer_pool_size设置为内存的70%-80%（约137GB-157GB），提升数据和索引的缓存命中率。

内容的提问来源于stack exchange，提问作者adnan illwa