会卡住复制，尤其5.7升8.0时ALTER TABLE默认COPY算法生成大临时表，阻塞binlog写入和从库SQL线程；若主库binlog_row_image=MINIMAL而从库不支持，复制直接报错。
MySQL 升级时 ALTER TABLE 生成的临时表会卡住复制吗
会，尤其是 MySQL 5.7 升级到 8.0 过程中，ALTER TABLE 默认使用 COPY 算法（即建新表、拷数据、rename）时，会产生大临时表，阻塞主从复制的 binlog 写入和从库 SQL 线程。更麻烦的是，如果主库在升级前启用了 binlog_row_image=MINIMAL，而从库是旧版本不支持该格式，复制直接报错 Could not execute Write_rows_v1 event on table。
- 升级前务必检查主从
binlog_format和binlog_row_image是否一致且兼容 - 对大表执行
ALTER TABLE前，先在从库停掉 SQL 线程：STOP SLAVE SQL_THREAD，避免堆积 - 优先用
ALGORITHM=INPLACE（如加普通索引、改列默认值），避免生成临时表；但注意：8.0.12+ 才支持INPLACE修改列类型，旧版本仍需COPY - 若必须用
COPY，配合pt-online-schema-change或gh-ost，它们不依赖原生ALTER，也不锁全表
MySQL 8.0 升级后 INFORMATION_SCHEMA 里临时表不见了
不是“不见了”，而是行为变了。MySQL 8.0 将 INFORMATION_SCHEMA 中的临时表（如 TEMPORARY TABLES）移除了——因为临时表只对当前会话可见，INFORMATION_SCHEMA 是全局视图，查不到合理。你看到的空结果或报错 Table 'INFORMATION_SCHEMA.TEMPORARY_TABLES' doesn't exist 就是这个原因。
- 想查当前会话有哪些临时表？用
SHOW TABLES LIKE '%'不行，得查performance_schema.session_status或直接看CREATE TEMPORARY TABLE的上下文 - 升级脚本里如果硬编码查询
INFORMATION_SCHEMA.TEMPORARY_TABLES，必须删掉或替换成会话级逻辑判断 - 临时表本身功能没变，仍是
CREATE TEMPORARY TABLE创建、会话退出自动销毁，只是元数据不暴露给INFORMATION_SCHEMA
升级期间如何安全变更表结构而不中断业务
核心原则：避免长事务 + 避免全表锁 + 避免 binlog 格式不兼容。MySQL 原生 ALTER TABLE 在多数场景下已不够用，尤其跨大版本升级时。
- 小表（NOT NULL 默认值），可用
ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE，但要确认存储引擎支持（InnoDB 支持，MyISAM 不支持） - 中大表推荐
gh-ost：它不依赖触发器，通过 binlog 解析增量，对主库压力小；注意升级前确保binlog_format=ROW且log_slave_updates=ON（即使单机也要开） - 禁用
pt-online-schema-change的--dry-run模式做升级预演——它会模拟但不真正执行，可提前暴露权限、磁盘空间、外键约束等问题 - 所有 DDL 必须在维护窗口内执行，并监控
information_schema.INNODB_TRX查是否有长事务阻塞
MySQL 8.0 的原子 DDL 对升级中表变更有什么实际影响
有，但仅限于“成功或失败”的语义保障，不解决性能或锁问题。MySQL 8.0 引入原子 DDL 日志（mysql.innodb_ddl_log），让单个 ALTER TABLE 操作要么全部完成，要么彻底回滚，不会出现“表结构改了一半、数据丢了”的中间态。
- 它不能避免临时表生成，也不能缩短执行时间；
ADD COLUMN仍可能扫全表，MODIFY COLUMN仍可能重建表 - 如果你的升级脚本里有多个
ALTER组合（比如先加列再建索引），原子 DDL 不保证它们整体原子——每个ALTER是独立原子的 - 升级后首次执行 DDL 会自动初始化
mysql.innodb_ddl_log表，无需手动操作；但如果升级前该表损坏，可能导致后续 DDL 卡死在Waiting for table metadata lock
临时表和表结构变更的复杂性，往往不在语法本身，而在版本间元数据存储方式、binlog 解析逻辑、以及复制通道的隐式依赖。升级前跑一次真实流量压测 + DDL 混合执行，比读十遍文档都管用。
