1）为什么大批量删除很危险？#

2）正确思路：分批删除#

最常见做法是：

按主键或索引范围，分批次删除，每次删少量。

例如每次删 1000 条：

1
DELETE FROM orders
2
WHERE id >= 1 AND id < 1001;

然后循环往下删。

或者：

1
DELETE FROM orders
2
WHERE create_time < '2023-01-01'
3
LIMIT 1000;

注意：如果用 LIMIT 删除，最好结合有序主键或索引条件，否则可能效率很差。

3）为什么分批删除更安全？#

因为每次删除的数据量小，可以做到：

• 事务短
• 锁持有时间短
• redo / undo / binlog 压力小
• 对线上影响更小
• 可以随时暂停

这是生产环境里最实用的方法。

4）分批删除的一般建议#

1
DELETE FROM orders
2
WHERE id BETWEEN 100001 AND 101000;

5）如果删除的是历史数据，更好的方式是什么？#

如果是按时间删除大量历史数据，且表结构允许，通常更推荐：

1
ALTER TABLE ... DROP PARTITION ...

6）能不能先删索引再删数据？#

这个说法在某些离线场景下成立，但在线业务表一般要非常谨慎。

理论上：

• 删除数据时索引越多，维护成本越高
• 所以先删索引再删数据，速度可能更快

但在线生产环境通常不这么干，因为：

• 删索引本身就有风险
• 删完索引可能影响线上查询
• 重建索引也可能很重

所以生产里更常见的仍然是：

• 分批删除
• 限速执行
• 错峰操作

7）删除后空间会立刻释放吗？#

通常不会。 InnoDB 删除记录后，空间一般是：

• 标记为可复用
• 不是立刻归还操作系统

如果想真正缩小表文件，可能要：

• OPTIMIZE TABLE
• 重建表
• ALTER TABLE ... ENGINE=InnoDB

但这些操作通常代价不小，要谨慎。

8）总结#

删除百万级数据的正确姿势：

1. 不要一条大 DELETE
2. 优先按主键 / 索引分批删除
3. 每批控制数量
4. 分批之间适当休眠
5. 错峰执行
6. 必要时考虑分区表或重建表方案

一句话总结：

大数据量删除的核心原则是：小批量、可中断、低冲击。

1）为什么大表加字段有风险？#

不同 MySQL 版本、不同字段类型、不同变更形式，对 ALTER TABLE 的影响差异很大。

大表加字段可能引发的问题有：

2）常见方案一：使用 Online DDL#

在较新版本 MySQL 中，某些加字段操作可以走在线 DDL，减少锁表影响。

例如某些场景下：

1
ALTER TABLE user ADD COLUMN remark VARCHAR(255) NULL;

可能支持较低影响的方式执行。

但要注意：

• 不是所有 DDL 都能真正“无锁”
• 不同版本、不同操作支持程度不同
• 仍需评估执行时间和 MDL 风险

3）常见方案二：pt-online-schema-change#

这是生产环境非常经典的方案。

工具：

pt-online-schema-change

它是 Percona 提供的在线改表工具。

4）常见方案三：先改从库，再主从切换#

如果系统有主从架构，可以考虑：

1. 先在从库做表结构变更
2. 验证从库正常
3. 主从切换
4. 再处理原主库

这种方式适合：

• 有完整主从切换能力
• 业务能接受切换窗口
• DBA 运维能力较强

5）常见方案四：新建表迁移#

对于特别大的表，有时会采用“新表迁移”方案：

1. 新建带新字段的表
2. 历史数据迁移
3. 增量双写
4. 校验
5. 切换流量
6. 下线旧表

这和不停机扩容思路很像，复杂但风险可控。

6）如果字段允许，优先加可空字段#

通常加一个：

• 可空字段
• 没有复杂默认值
• 末尾追加字段

相对风险更低。

例如：

1
ALTER TABLE user ADD COLUMN remark VARCHAR(255) NULL;

往往比：

• 非空字段
• 带复杂默认值字段
• 中间插入字段

更容易在线执行。

7）上线前要做什么准备？#

8）总结#

大表加字段常见可行方案有：

1. Online DDL
2. pt-online-schema-change
3. 先改从库再切换
4. 新表迁移双写切换

一句话总结：

大表加字段的关键不是 SQL 本身，而是如何在不阻塞业务的情况下安全变更表结构。

1）第一步：先确认是不是 mysqld 导致#

先在机器上用：

1
top

或者：

1
htop

确认 CPU 高占用的进程是不是 mysqld。

因为 CPU 飙升不一定是 MySQL，也可能是：

• Java 应用
• 代理层
• 系统任务
• 监控进程

如果确认是 mysqld，再继续往下查。

2）第二步：查看当前活跃 SQL#

最直接的方法：

1
SHOW FULL PROCESSLIST;

关注：

• 哪些 SQL 执行时间很长
• 哪些线程状态异常
• 是否有大量相同 SQL
• 是否有锁等待
• 是否有 Sending data、Sorting result、Copying to tmp table 等高消耗状态

3）第三步：分析是不是某条慢 SQL 导致#

如果发现某条 SQL 很突出，就进一步：

• 把 SQL 拿出来
• EXPLAIN
• 分析是否走索引
• 是否全表扫描
• 是否排序 / 临时表
• 是否扫了大量数据

CPU 飙高最常见原因之一就是：

• 差 SQL
• 缺索引
• 索引失效
• 大量回表
• 大量排序聚合

4）第四步：看是不是突然连接数暴涨#

有时不是单条 SQL 特别慢，而是短时间内大量请求同时打到数据库。

这会导致：

• 大量 session
• 并发解析 / 执行 SQL
• CPU 被打满

此时要看：

• 连接数是否异常增长
• 某个接口是否流量暴涨
• 是否有爬虫 / 攻击 / 重试风暴
• 应用是否连接泄漏

5）第五步：看是否有大排序 / 大聚合 / 临时表#

某些查询即使不是全表扫描，也可能因为：

• ORDER BY
• GROUP BY
• DISTINCT
• 大结果集排序
• 临时表操作

导致 CPU 使用很高。

这类 SQL 往往在 EXPLAIN 的 Extra 中能看到：

• Using temporary
• Using filesort

6）第六步：看是否有执行计划突变#

有时 SQL 本来没问题，但因为：

• 统计信息过期
• 数据分布变化
• 优化器选错索引

导致执行计划突然变差，CPU 飙升。

所以有时要对比：

• 正常时执行计划
• 出问题时执行计划

7）现场处理怎么做？#

1
KILL <thread_id>;

8）后续优化怎么做？#

根据原因不同处理：

9）总结#

MySQL CPU 飙升的排查思路：

1. 先确认是不是 mysqld
2. 看 processlist
3. 找高消耗 SQL
4. EXPLAIN 分析执行计划
5. 看连接数和流量是否异常
6. 必要时 kill 线程止血
7. 后续从 SQL、索引、流量、架构角度优化

一句话总结：

CPU 飙升通常不是“数据库坏了”，而是数据库在高成本执行某些请求，关键是快速定位“哪类 SQL 或哪波流量”导致。