pt-osc（Percona Toolkit 中的 pt-online-schema-change）在执行在线 DDL 时，会持续监控数据库负载。当检测到系统压力过大，它会自动暂停变更操作，避免影响线上业务——critical-load 就是触发这一保护机制的核心阈值参数。
critical-load 是什么？
它是一组以 variable=value 形式指定的 MySQL 状态变量阈值（如 Threads_running=25、Threads_connected=500），用于定义“当前负载过高”的判断标准。只要任一指标超过设定值，pt-osc 就认为系统处于 critical 状态，立即暂停 chunk 拷贝，进入等待状态。
常见用法示例：
--critical-load="Threads_running=30,Threads_connected=400"
自动暂停是怎么工作的？
pt-osc 在每个 chunk 执行前（以及每秒心跳检查时）都会查询 SHOW GLOBAL STATUS 和 SHOW GLOBAL VARIABLES，实时比对 critical-load 条件。一旦命中，它不会报错退出，而是：
- 停止当前 chunk 的 INSERT/UPDATE/DELETE 同步
- 保持原表与影子表结构一致，不丢数据
- 每隔
--check-interval秒（默认 1 秒）重新检查负载 - 直到所有 critical 指标回落至阈值以下，才继续执行下一个 chunk
哪些指标值得重点关注？
并非所有状态变量都适合放进 critical-load，应优先选择能真实反映瞬时压力的指标：
- Threads_running：真正正在执行的线程数，最常用、最敏感的指标
- Innodb_row_lock_time_avg：平均行锁等待时间，超长说明写竞争激烈
-
Slow_queries：慢查询数量突增可能预示性能拐点（需配合
--check-interval谨慎使用） - 避免使用
Uptime或Questions这类累积型指标，它们无法反映瞬时压力
调优建议与注意事项
设置 critical-load 不是越严越好，需结合业务低峰期实测调整：
- 上线前在从库或测试环境模拟压测，观察正常业务下的
Threads_running波动范围，将阈值设为峰值的 1.2–1.5 倍 - 若频繁暂停，可临时放宽阈值，或搭配
--max-load（非阻断式警告）一起用 - 注意：critical-load 只控制 chunk 暂停，不影响
--chunk-time或--sleep的节奏逻辑 - 日志中看到
Pause due to --critical-load即表示已触发暂停，无需人工干预
