MySQL 5.7 真正支持 LOCK=NONE 的 ALTER 操作极少：ADD COLUMN（无 NOT NULL/DEFAULT）、ADD/DROP INDEX、RENAME INDEX（需显式指定且 InnoDB）、RENAME COLUMN（5.7.6+）、增大 VARCHAR 长度（5.7.23+）；其余如 DROP COLUMN、CHANGE COLUMN、缩小字段、改类型、删主键等均重建表。
MySQL 5.7 原生 ALTER 对千万级表基本不可用——加字段、改类型、删列等操作大概率触发全表 COPY，锁表几十分钟起；真·在线（LOCK=NONE）仅限极少数场景，必须靠 pt-online-schema-change 或严格验证条件才能落地。
哪些 ALTER 操作在 MySQL 5.7 真正支持 LOCK=NONE？
别信“文档说支持”就直接上，实际执行时降级是常态。真正稳住 LOCK=NONE 的操作极少，且有硬性前提：
-
ADD COLUMN：5.7.5+ 支持，但字段不能带NOT NULL且无DEFAULT值，否则报错ERROR 1846 (HY000): ALGORITHM=INPLACE is not supported -
ADD INDEX/DROP INDEX：全部支持ALGORITHM=INPLACE, LOCK=NONE，并发 DML 不阻塞 -
RENAME INDEX：5.7+ 专属元数据操作，不读写数据页，但必须显式写ALGORITHM=INPLACE, LOCK=NONE，且表引擎必须是InnoDB -
RENAME COLUMN：5.7.6+ 支持，同RENAME INDEX，需反引号包裹名（如`old_col` TO `new_col`） -
MODIFY COLUMN增大VARCHAR长度（如VARCHAR(50) → VARCHAR(100)）：5.7.23+ 才较稳定，旧版本仍可能退化为 COPY
而 DROP COLUMN、CHANGE COLUMN、缩小字段长度、改数据类型（如 INT → BIGINT）、删主键等，一律重建表，LOCK=NONE 无效。
为什么显式写了 ALGORITHM=INPLACE, LOCK=NONE 还被锁死？
不是语法错，是 MySQL 在后台悄悄降级或被外部锁卡住：
- 长事务未提交：查
SELECT * FROM information_schema.innodb_trx WHERE TIME > 60，KILL 掉它；否则 DDL 卡在Waiting for table metadata lock - 慢查询持有 MDL_SHARED_READ 锁：比如没加索引的
SELECT ... FOR UPDATE，会阻塞 DDL 元数据变更 - 表引擎非 InnoDB：
SHOW CREATE TABLE t1确认ENGINE=InnoDB，MyISAM 不支持 INPLACE - 索引名冲突或含关键字：重命名索引时，
new_idx若已存在（哪怕类型不同），或含数字/下划线未加反引号，都会失败
验证是否真在线？别看 “Query OK”，开另一个会话持续 INSERT INTO t1 () VALUES ()，观察是否超时或锁等待；再查 information_schema.innodb_alter_table，若 state = 'copy to tmp table'，说明已退化。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
大表结构变更必须用 pt-online-schema-change
原生 ALTER 在千万级表上就是定时炸弹。pt-osc 是唯一靠谱选择，但它不是“开箱即用”，必须过四关：
- 原表必须有主键或唯一非空索引，否则报错：
Cannot chunk table `db`.`t`: no primary key or unique not-null index - 原表不能有任何触发器，否则提示：
Triggers exist on the table - 操作用户必须有
TRIGGER、REPLICATION SLAVE、PROCESS权限（光有SELECT/UPDATE不行） - 若有外键引用，必须加
--alter-foreign-keys-method=auto，否则RENAME阶段失败
生产参数必须调：用 --chunk-time=0.5 控制每批耗时上限（别碰 --chunk-size），设 --max-load="Threads_running=25" 防雪崩，--critical-load="Threads_running=50" 保底线，--max-lag=1 护从库延迟。执行完务必人工核对 SHOW CREATE TABLE t1 和用 pt-table-checksum 校验数据一致性——COUNT(*) 不可靠。
RENAME INDEX 看似简单，但最容易漏掉三件事
这是最常被当成“安全操作”却翻车的点：
- 忘记加
ALGORITHM=INPLACE, LOCK=NONE：不写就走默认策略，老版本或复杂表可能退化 - 索引名没加反引号：
ALTER TABLE t1 RENAME INDEX idx_2023 TO idx_v2在索引名含数字时会语法错误，必须写成`idx_2023` TO `idx_v2` - 执行后残留触发器：pt-osc 中断后，原表上可能留着
pt_osc_db_t1_del等触发器，得手动DROP TRIGGER IF EXISTS pt_osc_db_t1_del
批量重命名别手写 SQL，用 information_schema 自动生成语句更安全，比如查出所有 idx_ 开头的索引，拼 ALTER TABLE ... RENAME INDEX 批量执行。
