mysql生产系统引擎排查_列出所有MyISAM表的脚本

查 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引擎下）整理一下，然后再进行转换。

说到底，在线上修改存储引擎从来不是敲个命令就能完事的简单操作。表越大，准备工作就要越充分：评估执行计划、预估锁表时间、检查磁盘空间是否充足……这些后续步骤的复杂度，可比“怎么把表列出来”要高得多。