不能直接用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 写锁，是目前唯一可控的线上方案。但注意硬性前提和参数控制：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 确保
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 差异极大，不调参等于白转。重点改三项：
-
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 报错或主从断裂。
