DAS空间碎片自动回收需满足实例类型、创建时长、CPU规格、InnoDB引擎等硬性条件，并在可维护窗口内通过剩余空间、无备份任务、CPU使用率等多重检查后才执行。
自动回收表空间碎片不是开个开关就能跑起来的事，它依赖实例状态、配置阈值和运维窗口的多重校验。RDS MySQL 的 DAS 空间碎片自动回收功能默认不启用，且仅对满足硬性条件的表生效——多数人配完发现“没动静”，其实是卡在了前置检查上。
确认实例是否满足自动回收的前提条件
不满足任一条件，DAS 就不会把这张表纳入回收队列，也不会报错提示：
- 实例类型必须是 RDS MySQL 高可用系列、三节点企业版或集群版；MyBase MySQL 高可用版也支持
- 实例已创建满 14 天，且 CPU 规格 ≥ 4 核
-
innodb_file_per_table必须为ON（MySQL 5.6+ 默认开启，但需确认） - 目标表引擎必须是
InnoDB（用SHOW TABLE STATUS LIKE 't'查Engine字段） - 表空间大小必须在
[5, 100]GB 范围内（小于 5GB 或大于 100GB 的表直接跳过）
检查并配置 DAS 运维服务与可维护时间段
自动回收由 DAS 在实例的「可维护时间段」内触发，不是实时响应式任务：
- 必须先在 RDS 控制台为目标实例开启「DAS 运维服务」，否则功能不可用
- 可维护时间段默认为每日凌晨 2:00–6:00，可在控制台修改；DAS 只在这个窗口内尝试执行
- 每次尝试前会检查：实例剩余空间 ≥ 表物理大小的 3 倍、无备份任务、无结构变更、CPU 使用率低于 80%（且前两天同一时段均低于 70%）
- 若某次检查失败（如磁盘临时不足），DAS 会等 1–5 分钟重试；整个窗口都失败，则推迟到下个窗口再试
排除导致自动回收静默跳过的常见原因
即使表“看起来符合条件”，也可能被自动过滤掉，且不记录日志：
- 表上有
FULLTEXT全文索引 → DAS 直接跳过，不回收 - 存在运行超 3 秒的慢 SQL 或悬挂事务（持有锁 >15 秒未提交）→ 检查失败，暂停回收
- 活跃会话数 ≥ 64 → 触发限流保护，不执行
- 表上定义了虚拟列、外键约束或使用
ROW_FORMAT=COMPRESSED→ 部分版本中 OPTIMIZE 会静默失效，DAS 识别后跳过
验证自动回收是否真正生效
不能只看 DAS 控制台的“执行成功”状态，要确认磁盘空间是否实际释放：
- 登录数据库，执行
SELECT DATA_LENGTH, INDEX_LENGTH, DATA_FREE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't'，对比前后DATA_FREE是否显著下降 - 登录服务器，执行
ls -lh /var/lib/mysql/db_name/t.ibd，确认文件大小是否缩小（前提是innodb_file_per_table = ON） - 如果
.ibd文件大小不变，大概率是 undo log、change buffer 或 purge 线程阻塞导致空间未归还，不是自动回收本身的问题 - DAS 日志只记录“开始/结束时间”和“是否通过检查”，不记录每张表的具体回收效果，需自行核对
最易被忽略的一点：自动回收只在主实例上执行，且全程绕过从库复制延迟检测——如果从库 SQL_THREAD 已暂停或延迟严重，回收后的表结构变更可能卡在 relay log 里，造成主从不一致。上线前务必确认 SHOW SLAVE STATUS\G 中 Seconds_Behind_Master 为 0 且 SQL_THREAD 正常运行。
