MySQL执行ALTER TABLE后，若返回“0 rows affected”则极大概率使用INPLACE（含INSTANT）算法；非零值则明确为COPY算法，发生全表拷贝。
看执行结果里的“rows affected”是否为0
MySQL执行完一条ALTER TABLE语句后，客户端会返回类似Query OK, 0 rows affected或Query OK, 12345678 rows affected的信息。这是最直接、最可靠的判断依据：
-
0 rows affected→ 极大概率走的是INPLACE（含INSTANT）算法 - 非零数字（比如几十万、上千万）→ 明确是
COPY算法，发生了全表拷贝
这个规则在MySQL 5.6+所有主流版本中稳定有效，不依赖日志、不依赖权限、不需要查系统表，只要能看到执行反馈就能立刻判断。注意：不是看“耗时长短”，也不是看有没有报错，就盯住这一行输出。
用SHOW WARNINGS确认ALGORITHM实际选择
即使你没显式指定ALGORITHM=INPLACE，MySQL也会按规则自动选。执行完DDL后立刻运行SHOW WARNINGS，常能看到类似这样的提示：
Level: Note Code: 1872 Message: InnoDB: Online DDL: CREATE INDEX will use ALGORITHM=INPLACE
这类Note级提示明确告诉你底层用了什么算法。但要注意：
- 它只在MySQL认为有必要提醒时才出现，不是每次都有
- 如果看到
ALGORITHM=COPY或Using temporary table字样，说明降级了 - 若提示
ALGORITHM=DEFAULT，得结合rows affected再判断，因为DEFAULT只是策略，不是结果
查information_schema.INNODB_TRX和performance_schema.events_statements_current辅助验证
当DDL执行时间较长、你怀疑它卡在某个阶段时，可以查活跃事务和当前语句状态：
- 运行
SELECT * FROM information_schema.INNODB_TRX WHERE trx_query LIKE 'alter%';，观察trx_state和trx_operation_state。若长时间停留在creating index或copy to tmp table，基本可断定是INPLACE rebuild或COPY - 查
performance_schema.events_statements_current里对应线程的SQL_TEXT和WORK_COMPLETED（如果启用了相关instrument），能反映是否在刷row log或重放日志 - 这些方法不能替代
rows affected判断，但能帮你定位INPLACE内部是no-rebuild（快）还是rebuild（慢且IO高）
别信“加字段就一定INSTANT”这种经验主义
MySQL 8.0.12+虽然默认启用INSTANT，但它只支持极有限的操作：
- 仅
ADD COLUMN（末尾添加，且不能是主键/自增/全文索引列） - 不支持
ADD COLUMN FIRST、MODIFY COLUMN、CHANGE COLUMN、DROP COLUMN等——这些仍会退回到INPLACE甚至COPY - 如果表有
ROW_FORMAT=COMPACT或存在TEXT/BLOB列且未启用innodb_strict_mode，INSTANT也可能被跳过
真正容易被忽略的点是：同一张表上连续执行多个DDL，哪怕第一个是INSTANT，第二个可能因元数据状态变化而触发INPLACE rebuild——所以每次都要单独验证，不能凭前一次结果推断下一次。
