查 MyISAM 表：直接用 information_schema 查引擎类型
在MySQL生产环境里，混合使用多种存储引擎的情况并不少见。但问题在于，MyISAM引擎天生缺乏事务支持和行级锁，一旦遇到高并发写入或者需要崩溃恢复的场景，就很容易“掉链子”。所以，排查工作的第一步，就是得快速、准确地揪出那些还在用MyISAM的表。
怎么查最靠谱？答案是直接查询 information_schema.tables 系统表。这个视图能实时反映表的当前引擎状态，比去翻看建表语句或者用 SHOW CREATE TABLE 要可靠得多——毕竟后者显示的可能是“历史文档”，万一有人手动改了脚本却没实际执行 ALTER 操作呢？
- 核心查询语句长这样：
SELECT table_schema, table_name, engine FROM information_schema.tables WHERE engine = 'MyISAM' AND table_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys'); - 后面那个
table_schema NOT IN (...)条件可不能省。系统库里的MyISAM表（比如经典的mysql.help_topic）通常不用动，也动不了。 - 如果只想聚焦某个特定数据库，把排除条件换成
AND table_schema = 'your_db'就行。 - 需要提醒的是：这个查询本身不会锁表，但如果频繁扫描一个拥有海量表的
information_schema，可能会引发元数据锁等待。稳妥起见，还是建议在业务低峰期执行。
为什么不能只靠 SHOW ENGINES 或 SHOW VARIABLES
有些朋友可能会想走捷径，但这两条路其实都行不通。SHOW ENGINES 命令只是告诉你“MyISAM引擎是否被支持”，而不是“哪些表正在用它”。至于 SHOW VARIABLES LIKE 'default_storage_engine'，它仅仅反映了默认的存储引擎设置，对已经存在的表毫无影响。
- 一个常见的误区是：明明早就把
default_storage_engine设成了InnoDB，就以为万事大吉。殊不知，那些历史遗留的MyISAM表依然“健在”。 - 很多老旧的应用程序在建表语句里会显式写上
ENGINE=MyISAM，如果后来没人主动去改，它们就会一直保持原样。 - 当然，
SHOW CREATE TABLE确实能查看单个表的引擎，可一旦面对成百上千个库、数以万计的表，用这种方式批量排查，效率就太低了，根本不现实。
脚本化排查：加过滤、导出、防误操作
在生产环境操作，可不能只靠手动敲几条SQL。最佳实践是把整个流程封装成可复用的脚本，并且要加上必要的防护措施，核心目标是避免漏查、误查，同时处理好权限和超时问题。
- 使用类似
mysql -u$user -p$pass -e "..."的命令行执行时，记得加上--skip-column-names --batch参数。这样输出结果会更干净，方便后续用awk或者while read循环来处理。 - 在查询语句里加上
ORDER BY table_schema, table_name，能让输出结果顺序固定、可预测，方便和之前的历史报告做对比（diff）。 - 如果执行时遇到
Access denied for user错误，得先确认连接账号是否拥有对information_schema数据库的SELECT权限——这一点经常被忽略。 - 对于超大型数据库实例（比如表数量超过10万），查询
information_schema可能会超时。这时可以临时设置SET SESSION innodb_stats_on_metadata = OFF;来减少统计开销，这通常不会影响线上业务。
MyISAM 表迁移前必须验证的三件事
找到MyISAM表只是万&里长征第一步。真要动手把它们转成InnoDB，如果直接无脑执行 ALTER TABLE t ENGINE=InnoDB，那风险可就大了。在转换之前，至少得确认下面这三件事：
- 检查全文索引：MyISAM的全文索引语法和InnoDB不完全兼容。如果表上有，需要先删除，等转换完成后再用InnoDB的语法重建。
- 确认自增列属性：MyISAM允许
AUTO_INCREMENT字段作为非主键索引的一部分，但InnoDB要求自增列必须是主键，或者至少包含主键前缀。结构不符会导致转换失败。 - 评估表体积：通过
DATA_LENGTH + INDEX_LENGTH计算一下表大小。如果发现MyISAM格式的表体积远大于它转为InnoDB后的预期，那很可能存在大量碎片或冗余索引。这种情况下，直接转换会耗时极长且可能锁表，更稳妥的做法是先用OPTIMIZE TABLE（在MyISAM引擎下）整理一下，然后再进行转换。
说到底，在线上修改存储引擎从来不是敲个命令就能完事的简单操作。表越大，准备工作就要越充分：评估执行计划、预估锁表时间、检查磁盘空间是否充足……这些后续步骤的复杂度，可比“怎么把表列出来”要高得多。
