alter table修改存储引擎会重建表：新建空表、逐行复制数据、重建索引、原子替换；期间加读锁阻塞写操作，耗i/o与临时空间，失败则回滚不丢数据，但需备份并验证兼容性。
ALTER TABLE 是最直接的手段，但“不丢失数据”不等于“零风险”——它确实保留所有行、索引和约束，但会锁表、耗资源、可能失败。真正安全的前提是：你已备份，且清楚新结构对现有应用的兼容性影响。
ALTER TABLE 执行时到底发生了什么
MySQL 并不是就地修改表定义，而是重建整张表：ALTER TABLE 会新建一个空表（用新结构），逐行复制原表数据，重建索引，最后原子替换。这个过程对原表加读锁（SELECT 可继续，但 INSERT/UPDATE/DELETE 会被阻塞）。
- 复制期间占用大量磁盘 I/O 和临时空间；大表容易触发
tmp_table_size或innodb_log_file_size不足而中断 - 若中途失败（如磁盘满、连接断开），原表不受影响，操作回滚——不是丢数据，是没改成功
-
ENGINE=InnoDB会自动启用事务支持，但不会帮你补外键；如果原表有FULLTEXT索引（MyISAM 特有），改完就失效，必须手动重建
为什么 SHOW CREATE TABLE 比 SHOW TABLE STATUS 更可靠
SHOW TABLE STATUS LIKE 'table_name' 只返回 Engine 字段，但在复制延迟高、或 information_schema 缓存未刷新时可能滞后或不准。真正验证是否生效，必须看建表语句：
- 执行
SHOW CREATE TABLE table_name; - 检查输出中
ENGINE=后面的值，并确认CREATE TABLE语句里没有残留的 MyISAM 特有语法（比如DELAY_KEY_WRITE=1），这些字段在 InnoDB 下会被忽略，但说明结构未完全适配 - 若看到
ENGINE=InnoDB且无警告，基本算成功；若仍显示ENGINE=MyISAM，大概率是语句没执行成功（权限不足、表名拼错、或被 SQL mode 拦截）
大表结构变更时三个硬限制容易被忽略
当表超过 1GB 或百万级行数，ALTER TABLE 很可能卡住或失败，不是因为语法错，而是底层资源瓶颈：
-
innodb_buffer_pool_size过小：复制过程频繁刷脏页，导致性能雪崩；建议至少设为物理内存的 50%–75% -
max_allowed_packet不够：如果某一行超长（比如含巨大TEXT字段），复制时会报错Packets larger than max_allowed_packet are not allowed - 磁盘剩余空间不足：重建过程需要至少等量的临时空间；别硬扛，改用
CREATE TABLE ... LIKE+INSERT INTO ... SELECT分批导入更可控
真正不锁表的方案：pt-online-schema-change
对于生产环境中的大表或高可用要求场景，ALTER TABLE 的锁表行为不可接受。Percona 的 pt-online-schema-change 工具通过影子表+触发器机制实现在线变更：
- 它不依赖 MySQL 原生 Online DDL，兼容 5.6+ 所有版本
- 全程允许读写，但会增加主从延迟、触发器开销和额外磁盘占用
- 必须提前检查触发器权限、binlog 格式（需
ROW）、以及目标列是否含NOT NULL且无默认值（否则INSERT会失败） - 执行前务必在测试库完整走一遍流程，观察慢查询日志和
SHOW PROCESSLIST中的复制线程状态
MODIFY COLUMN 操作在应用层已有隐式类型转换逻辑，改完反而引发 PHP 或 Java 层的数值截断；又比如 CHANGE COLUMN 重命名后，ORM 映射没同步更新，查不到字段却不报错。这些都不是数据库的问题，但最容易被忽略。
