背景

清理磁盘空间MySQL 清理磁盘空间 ，导致OPTIMIZE 收缩表 cpu100%

最终使用阿里云无锁变更完成表收缩

warning 先看风险

1. 晚上用户少的时候执行（如果晚上定时任务多，cpu 占用比白天还高，也不要再白天执行，出现问题说不清楚）
2. 低版本 mysql （**CPU pegged at 100% after optimizing table belonging to merge set （）**可能会出现这个 bug——具体的 rds 日志上没有看到，表现出来的就是如标题所说，这个 bug 还关联了另一个 bug，很早以前已经被解决（问题表象看起来和这个描述的一样）
   1. 按原理讲，应该不会有这样问题
3. 条件允许情况下，一定要先备份后执行
4. 从小表到大表
5. 分批分天执行，不要一次性操作完
6. 收缩的时候会占用该表2~3倍空间，空间要充足
   1. 阿里云 RDS 介绍：回收大容量表的碎片空间时，请确保实例剩余的存储空间大小至少为目标表大小的2~3倍，并在变更过程中密切关注实例剩余空间情况。
   2. 说明回收大容量表的碎片空间时，可能需要临时存储数据的副本或其他，这可能会导致额外的空间需求。如果空间不足，可能会导致回收碎片空间的操作失败或者实例被锁定。
7. 对大表进行optimize table操作会带来突发的IO和Buffer使用量，可能导致锁表和抢占资源，业务高峰期可能会导致实例不可用以及监控断点。建议在业务低峰期操作。

执行SQL

# 两种应该都可以
ALTER TABLE ay_trade_main_6 FORCE, ALGORITHM=INPLACE, LOCK=NONE;

**OPTIMIZE TABLE kefu.aigc_images_scene_match;**

为什么这么做

阿里 RDS 介绍

使用delete语句删除数据时，delete语句只是将记录的位置或数据页标记为了“可复用”，但是磁盘文件的大小不会改变，即表空间不会直接回收。此时您可以通过optimize table语句释放表空间。

对大表进行optimize table操作会带来突发的IO和Buffer使用量，可能导致锁表和抢占资源，业务高峰期可能会导致实例不可用以及监控断点。建议在业务低峰期操作。

IO 和 Buffer 操作，那个表也没有人用，导致 CPU 100% 确实不在意料之中