不能直接用ALTER TABLE转大表，因MySQL 5.7/8.0不支持INPLACE，强制COPY算法会导致全程MDL写锁、磁盘空间翻倍、主从延迟激增；大表（>500MB）必须用pt-online-schema-change，依赖主键/唯一索引和innodb_file_per_table=ON，并需手动清理旧文件及调优InnoDB参数。

不能直接用 ALTER TABLE t ENGINE=InnoDB —— 它会在大表上全程锁写、吃光磁盘、拖垮主从，且 MySQL 5.7/8.0 均不支持 ALGORITHM=INPLACE。

先确认这表真该转，且能转

盲目转换可能触发全文索引报错、AUTO_INCREMENT 失效或性能倒退。必须逐项验证：

• 查引擎：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 't';
• 查全文索引：SHOW INDEX FROM t WHERE Key_name = 'FULLTEXT'; —— 若存在且 MySQL ALTER 会直接失败
• 查主键/唯一索引：SHOW KEYS FROM t WHERE Non_unique = 0 AND Seq_in_index = 1; —— pt-online-schema-change 强制要求此项，否则报错 This table has no primary key or unique index
• 查 AUTO_INCREMENT 列是否已建索引：若没索引，ALTER 会报 ERROR 1075；MyISAM 允许，InnoDB 不允许

大表（>500MB）必须用 pt-online-schema-change

它通过影子表 + 触发器双写绕过 MDL 写锁，是目前唯一可控的线上方案。但注意硬性前提和参数控制：

• 确保 innodb_file_per_table = ON（MySQL 5.6+ 默认开启），否则新表无法生成独立 .ibd 文件
• 命令示例：pt-online-schema-change --alter "ENGINE=InnoDB" D=your_db,t=big_table --execute
• 关键参数必须显式设置：--chunk-size=1000（控制每批迁移行数）、--max-lag=1（从库延迟超 1 秒自动暂停）、--check-interval=5（每 5 秒检查一次）
• 迁移完成后，.MYD 和 .MYI 文件不会自动删除，需人工确认数据一致后手动清理

转换后必须调参，否则 InnoDB 可能比 MyISAM 还慢

InnoDB 行为与 MyISAM 差异极大，不调参等于白转。重点改三项：

Mysql Skill 1.0.0 (3)

MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。

下载

• innodb_buffer_pool_size 设为物理内存的 50%–75%（你机器有 24G 内存，就设 12G 起）
• key_buffer_size 从几百 MB 降到 32M 左右（MyISAM 专用缓存，InnoDB 不用）
• innodb_flush_log_at_trx_commit 非金融场景可设为 2（提升写入吞吐，牺牲极小概率的事务持久性）

验证不能只看 SHOW TABLE STATUS

引擎字段变 InnoDB 只是第一步。真正容易被忽略的是行为一致性：

• 跑 COUNT(*) 对比原表，确认行数一致（InnoDB 不维护精确计数器）
• 重放业务 SQL，尤其检查含 MATCH AGAINST 的全文查询是否仍可用（若原表有 FULLTEXT，且版本 ≥5.6.4，需重建索引）
• 监控 Seconds_Behind_Master 和 SHOW PROCESSLIST 中是否有 copy to tmp table 残留（说明有漏网的 ALTER 在后台运行）

最复杂的点不在转换动作本身，而在转换前的兼容判断和转换后的参数适配——这两步跳过，轻则性能反降，重则业务 SQL 报错或主从断裂。