可以对 information_schema 崩溃表进行 mysql 查询吗？

Posted 2023-02-24

【中文标题】可以对 information_schema 崩溃表进行 mysql 查询吗？

【英文标题】：Can a mysql query done on information_schema crash tables?

【发布时间】：2017-11-15 13:22:54

【问题描述】：

我使用的软件使用的是 mysql 服务器（版本 5.0.52）。 一些数据库是动态创建的，我需要列出这些数据库的名称（标准是包含 2 个具有不同特定名称的表的数据库）。因此，我在 information_schema 上使用 mysql 查询来查找我需要的内容：

SELECT distinct T.table_schema  
FROM information_schema.`TABLES` T 
inner join information_schema.`TABLES` T2  
on T2.table_schema = T.table_schema  
where T.table_schema like 'myBase_%' 
and T.table_name like '%\_1' 
and T2.table_schema like 'myBase_%' 
and T2.table_name = 'myTable'

MySQL 服务需要每 2 或 3 周手动重新启动一次，因为某些表似乎已崩溃或锁定。来自 pid3306_crash.err 的错误消息（这是第一个错误，但是一旦我有了这一行，软件尝试查询的每个表都会出现此错误，给我 5000 行“找不到文件”）：

[ERROR] D:\MySQL\MySQL Server 5.0\bin\mysqld-nt: Cannot find the file: '.\myBase_56320\petiquettes_k_1.frm' (Errcode: 22)

我为这个 mysql 实例启用了完整的日志，唯一可以访问这个表的 mysql 查询是我引用的那个。没有与上面引用的第一个错误相关的任何其他查询。 所以我的问题是：关于 information_schema 的查询是否有可能使我的基础崩溃，或者我应该看看其他地方吗？

谢谢。

【参考方案1】：

MySQL 5.0.52 已经过时了——将近 10 年了。 5.0 已经被弃用很久了，但同时修复了很多很多错误——最后一个 5.0.x 版本是 5.0.96。

对 information_schema 的查询更有可能揭示与数据损坏相关的问题（例如硬盘驱动器故障或赎金内存错误），但这并不超出错误导致碰撞。

所以......它不应该，但它可能。

information_schema 表并不是真正的表——它们是内部服务器内存和磁盘结构的 SQL 接口。

下一步（除了迁移到更新版本的 MySQL 服务器之外）是使用临时表减少对 information_schema 代码的需求。

USE test; /* or some other schema, NOT information_schema */
CREATE TEMPORARY TABLE ist1 AS SELECT * FROM INFORMATION_SCHEMA.TABLES;
CREATE TEMPORARY TABLE ist2 AS SELECT * ist1;

请注意，您应该只选择必要的列，因为这可能会降低服务器探测其内部以满足您的查询的深度。

现在，您有两个临时表 ist1 和 ist2，其中包含来自 information_schema.tables 的快照。重写您的原始查询以使用这些。它们将一直存在，直到您与服务器断开连接，然后它们将被自动删除。

【讨论】：

我知道版本真的很旧了，但是由于许可证问题和工作环境的兼容性问题，我不花几个月的时间就无法升级，而且我没有时间去做现在。我将尝试进一步查看日志以尝试解释它。我会尝试使用临时表来查看它是否有任何改变，谢谢。