MySQL系统库中的日志表（如slow_log、general_log）根本不能改引擎，仅支持CSV和MyISAM，InnoDB被内核硬编码拒绝，执行ALTER TABLE会报ERROR 1031。
不能直接对日志表（如 mysql.slow_log、mysql.general_log）执行 ALTER TABLE ... ENGINE=InnoDB —— 官方明确禁止，会报错。
哪些表根本改不了引擎？
MySQL 系统库中的日志表只支持 CSV 和 MyISAM 引擎，InnoDB 被硬编码拒绝。执行时会直接报错：
ERROR 1031 (HY000): Table storage engine for 'slow_log' doesn't support this operation
这不是权限或配置问题，是 MySQL 内核层的限制。背后原因主要是避免日志写入路径引入 redo/undo 开销，影响性能和稳定性。
如果你真想加速查慢日志，只能走曲线救国：导出数据到新 InnoDB 表，加索引后再查，原日志表保持不动。
ALTER TABLE t ENGINE=InnoDB 大表为什么卡住？
这条语句在 MySQL 8.0+ 仍需 COPY 算法，不是 INPLACE。它会：
- 重建整张表：逐行读原表、写新表，期间对原表加
MDL读锁（阻塞所有ALTER/DROP），对写操作加表级写锁（INSERT/UPDATE/DELETE全部排队） - 临时空间吃紧：若原表 5GB，临时文件可能峰值占用 10GB+（含排序、索引构建）
- 事务日志暴涨：尤其当
innodb_flush_log_at_trx_commit=1时，大量小事务刷盘拖慢速度
别信“就几十万行没事”——字段含 MEDIUMTEXT、二级索引多、磁盘 I/O 差的机器上，10 分钟起跳很常见。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
MyISAM 转 InnoDB 前必须检查的三件事
跳过这些检查，轻则迁移失败，重则线上写入中断或主键失效：
-
有没有主键？ MyISAM 允许无主键；InnoDB 会静默创建隐藏
ROW_ID，但无法被业务引用，后续加主键要全表扫描+锁表。务必先执行：ALTER TABLE t ADD id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY FIRST; -
自增列是否在主键最左？ MyISAM 支持
(name VARCHAR(20), id INT AUTO_INCREMENT)这种主键；InnoDB 要求自增列必须是主键第一列，否则报错ERROR 1075。 -
全文索引怎么处理？ MySQL 5.6+ InnoDB 支持
FULLTEXT，但分词器、停用词、最小词长（innodb_ft_min_token_size）默认值和 MyISAM 不同。迁移后必须重建：ALTER TABLE t DROP INDEX ft_idx, ADD FULLTEXT(name, content);
大表安全迁移的实操路径
超过 1GB 或无法停写的服务，别碰 ALTER TABLE ... ENGINE。用 pt-online-schema-change 是目前最稳的选择：
pt-online-schema-change \ --alter "ENGINE=InnoDB" \ --execute \ --host=localhost \ --user=root \ --database=db_name \ --table=t_big_table
它通过触发器捕获增量变更，分批拷贝数据，全程不锁原表写入。但要注意：
- 目标表名不能和原表同名（工具自动处理，但别手动干预）
- 原表不能有外键（
FOREIGN_KEY_CHECKS=0也无效，工具会直接退出） - 确保磁盘剩余空间 ≥ 原表大小 × 2（含临时表、binlog、undo）
迁移完立刻验证：比对 SELECT COUNT(*)（同一事务隔离级别下）、抽样校验几行 MD5(CONCAT(...))、确认索引命中 EXPLAIN。
最容易被忽略的是字符集排序规则（collation）隐式变化——MyISAM 表用 utf8mb4_general_ci，新建 InnoDB 表可能继承 server 默认的 utf8mb4_0900_as_cs，导致 JOIN 或 ORDER BY 结果不一致。建表时显式指定 collation 更稳妥。
