mysql 5.7在线加索引本身不直接导致写入超时，但会因innodb_online_alter_log_max_size默认仅128mb而易触发db_online_log_too_big错误；需调大该参数并配合pt-online-schema-change的chunk-size、max-load等限流配置，同时优化索引数量与io策略。
MySQL 5.7 在线加索引本身不会直接导致写入超时，但会显著放大已有锁竞争、日志溢出或 I/O 压力，最终触发 DB_ONLINE_LOG_TOO_BIG 或 Lock wait timeout exceeded 这类错误。
innodb_online_alter_log_max_size 不够用是高频报错根源
在线 DDL（如 ADD INDEX）期间，InnoDB 用一个临时日志（row log）记录并发 DML 变更。这个日志大小上限由 innodb_online_alter_log_max_size 控制，默认仅 128MB。
- 108GB 表在建索引过程中若持续有高并发 INSERT/UPDATE，几秒内就可能撑爆该日志
- 一旦超过阈值，操作立刻失败，报错
DB_ONLINE_LOG_TOO_BIG，且未提交的 DML 全部回滚 - 该参数不能动态修改，必须写入
my.cnf并重启 MySQL；建议大表场景设为512M或1G（需结合磁盘空间评估） - 注意：调大它不等于“更安全”，只是延长了容忍窗口；最终仍需控制 DML 流量或缩短 DDL 时间
pt-online-schema-change 的 chunk-size 和负载参数直接影响超时风险
当原生 Online DDL 不够稳时，多数人转向 pt-online-schema-change，但它默认行为极易引发写入延迟累积甚至超时。
-
--chunk-size=1000（默认）会导致频繁 IO 切换和小事务堆积，容易被innodb_lock_wait_timeout捕获并中断 - 必须显式加大：
--chunk-size=10000或更高（视单行大小和 buffer pool 而定），减少事务数量和锁持有频次 -
--max-load="Threads_running=50"是关键限流开关——若不设，工具会在系统高负载时继续切块，加剧锁等待 - 务必配
--set-vars='innodb_lock_wait_timeout=60,lock_wait_timeout=50'，避免工具自身被超时中断
写入变慢不是“加索引”本身的问题，而是索引维护与日志刷盘叠加的结果
你看到的 INSERT 变慢、连接卡在 updating 状态，大概率是以下两个机制同时起效：
- InnoDB 必须为每条新记录同步更新所有二级索引，B+ 树插入 + 页分裂 + 回表路径维护，索引越多开销越非线性增长
-
innodb_flush_log_at_trx_commit=1（默认）强制每次 COMMIT 都 fsync redo 日志，而建索引期间 DML 密集，IO 瓶颈被彻底暴露 - 临时解决方案：对非核心表，可临时设为
2（需同步调大innodb_log_buffer_size和innodb_log_file_size），但不可用于金融类事务 - 根本解法：确认是否真需要那么多索引——用
sys.schema_unused_indexes查看长期未命中的索引，删掉它们比调参更有效
真正危险的不是参数调得不够多，而是把 innodb_online_alter_log_max_size 设得过大却忽视了 DML 流控，或者在没关监控的情况下盲目加大 chunk-size 导致单次锁表时间翻倍。线上操作前，先在测试环境用 SHOW PROCESSLIST 和 INFORMATION_SCHEMA.INNODB_METRICS 观察锁等待和日志写入速率，比任何文档都管用。
