【数据库实战】RDS CPU突发打满：慢SQL紧急熔断与无锁重建索引的工程解法

在云端高并发场景下，如果发布的新功能夹带了一条缺乏有效索引的“全表扫描”SQL，瞬间就能耗尽 RDS 实例的所有 CPU 时间片。此时数据库连接池会迅速堆积打满，常规的重启实例不仅极度耗时，还可能引发更大规模的缓存击穿。标准的应急工程解法是：先杀异常会话止血，再通过无锁 DDL 补齐索引。

1. 紧急定位并熔断异常会话 CPU打满时，云端监控面板往往会有延迟。必须直接通过高权限账号连入 RDS，揪出执行时间极长、处于 Sending data 状态的幽灵线程：

-- 1. 按照执行时间倒序，找出当前执行超过 10 秒的阻塞查询
SELECT id, user, host, db, command, time, state, info 
FROM information_schema.processlist 
WHERE command = 'Query' AND time > 10 
ORDER BY time DESC;

-- 2. 拿到异常线程 ID (如 102553) 后，果断执行 kill 强制释放 CPU 算力
KILL 102553;

2. 提取慢 SQL 并通过 EXPLAIN 定界 止血后，立刻提取导致问题的 SQL 语句，并在前方加上 EXPLAIN 关键字查看执行计划。如果发现 type 列为 ALL（全表扫描），且 rows 扫描行数达到百万级，即可锁定故障元凶字段。

3. 执行在线无锁加索引（Online DDL） 锁定问题字段后需要立刻加索引。但在生产环境的千万级大表中直接 CREATE INDEX 极易锁表，导致业务彻底瘫痪。必须使用 MySQL 的 Online DDL 语法，强制声明不阻塞读写：

-- 针对 orders 表的 user_id 字段添加索引，并强令底层不阻塞当前业务的并发 DML
ALTER TABLE user_orders 
ADD INDEX idx_user_id (user_id), 
ALGORITHM=INPLACE, 
LOCK=NONE;

总结： 面对云数据库的突发算力瓶颈，盲目花钱升级 RDS 实例规格（Scale-Up）是低效的下策。通过 SHOW PROCESSLIST 实施精准的会话级熔断，配合底层的在线无锁 DDL 技术，我们能够在不中断前端读写的前提下，以极小的外科手术式操作，瞬间化解数据库层面的性能危机。