MySQL 5.6+支持Online DDL添加索引，核心是ALGORITHM=INPLACE与LOCK=NONE组合；需预调innodb_online_alter_log_max_size防日志溢出，并避开长事务与并发DDL，确保低影响执行。
在业务高峰期给大表加索引，核心不是“能不能做”，而是“怎么让影响降到最低”。MySQL 的 INNODB_ONLINE_ALTER_LOG_MAX_SIZE 参数本身不直接控制加索引行为，真正起作用的是 Online DDL 机制（由 ALGORITHM 和 LOCK 子句驱动），而 innodb_online_alter_log_max_size 是支撑该机制稳定运行的关键“安全阀”。
明确 Online DDL 是否真正启用
加索引是否在线，取决于 MySQL 版本、存储引擎和操作类型：
- 仅 InnoDB 表（无外键、无全文索引）添加非主键/非唯一索引时，MySQL 5.6+ 才可能支持
LOCK=NONE - 执行前务必验证：运行
ALTER TABLE t ADD INDEX idx_col (col), ALGORITHM=INPLACE, LOCK=NONE;—— 若报错 “ALGORITHM=INPLACE is not supported”，说明当前操作不满足在线条件，需换方案 - MySQL 8.0+ 支持并行索引构建，可显著缩短耗时，建议开启：
SET SESSION innodb_parallel_read_threads = 4;（根据 CPU 核数调整）
调优 innodb\_online\_alter\_log\_max_size 防止中途失败
这个参数决定了 Online DDL 过程中能缓存多少“增量变更日志”（Row Log）。如果业务写入频繁，日志超限会直接报错 DB_ONLINE_LOG_TOO_BIG，导致操作中断甚至回滚。
- 默认值 128MB 往往不够用，尤其在亿级表 + 高频更新场景下
- 建议按经验预估并临时调大：
SET SESSION innodb_online_alter_log_max_size = 536870912;（即 512MB） - 注意：该值过大虽降低失败风险，但会使最终“应用日志”的锁表时间变长（因为要一次性回放更多变更），所以不宜盲目设为几 GB
避开阻塞源头：严查长事务与并发 DDL
Online DDL 本身不长期锁表，但它在开始和结束阶段需要短暂的元数据锁（MDL）。一旦被卡住，整个表的读写都会被连锁阻塞。
- 执行前必查长事务：
SELECT trx_id, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) sec FROM information_schema.innodb_trx WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60; - 确认无其他 ALTER 正在运行：
SHOW PROCESSLIST;中查找状态为altering table或waiting for table metadata lock的线程 - 如有长事务，优先协调业务方提交或终止，切勿强行加索引
监控与兜底：边跑边看，随时可停
加索引是 IO/CPU 密集型任务，高峰期必须实时盯控资源水位：
- 观察进度：
SELECT * FROM performance_schema.table_io_waits_summary_by_table WHERE OBJECT_SCHEMA='your_db' AND OBJECT_NAME='your_table'; - 检查系统负载：重点关注
iostat -x 1中 %util 是否持续 >95%，top中 mysqld CPU 是否打满 - 若发现磁盘 IO 打满或从库延迟飙升，可安全中断：
KILL {pid}（MySQL 5.7+ 支持可中断的 Online DDL） - 紧急情况下，优先降级使用
pt-online-schema-change或gh-ost，它们对主库资源冲击更可控
