InnoDB 二级索引页分裂后，OPTIMIZE TABLE 的触发时机怎么判断？有没有可量化的阈值

【背景】 我负责一张 800 万行的订单宽表（InnoDB, MySQL 8.0.32），带 6 个二级索引。业务上每天约 30% 的行会被批量 UPDATE status 字段，持续一个月后观察到查询性能明显退化。

【现象】

1. SHOW TABLE STATUS 里 Data_free 从初始 0 涨到 2.3GB；
2. 同一条按 order_id 点查的 SQL，P99 从 8ms 涨到 45ms；
3. EXPLAIN 的 rows 估算值偏大（实际命中 200 行，估算 1200 行），怀疑是统计信息滞后叠加索引页分裂导致 B+ 树变"胖"、随机 IO 增加。

【已尝试与结果】

• ANALYZE TABLE 后立即复查：rows 估算值改善，但 P99 几乎没动（仍 40ms+）；
• 低峰期跑 OPTIMIZE TABLE：耗时 47 分钟，完成后 P99 回落到 9ms，Data_free 归零；
• 之后 2 周 Data_free 又慢慢涨回 ~1.5GB，P99 回到 30ms+，说明分裂是持续发生的。

【卡点】

• 目前只能靠"Data_free 超过 X GB"或"P99 超过 Y ms"拍脑袋触发 OPTIMIZE，缺乏更精确的指标；
• OPTIMIZE TABLE 在 800 万行表上耗时近 50 分钟，虽然 8.0 走 online DDL，但期间 IO 压力大，对同实例其他查询有挤压；
• 不确定 innodb_buffer_pool 的页命中率、索引页 fill factor 这些指标能否比 Data_free 更早、更准地预警"该合并了"。

【期望得到的答案形态】

1. 一个可操作的判断标准：具体看哪个指标（或哪几个指标组合）+ 阈值怎么定，最好能附监控 SQL 或 performance_schema 查询；
2. 比 OPTIMIZE TABLE 更轻量的替代方案（如 pt-online-schema-change、ALTER TABLE ... ENGINE=InnoDB、或者针对单个索引的 REBUILD）；
3. 如果你们有类似场景（高更新率的宽表 + 多二级索引），实际用的策略和踩过的坑也欢迎分享。