《一问一实验：AI 版》在 MySQL 日志中发现有大量报错，可能是什么原因造成的？

🥳 社区王牌专栏《一问一实验：AI 版》全新归来，在 520 这个充满爱的特殊日子里，献上一份属于 DBA 们的爱（AI）。

什么是《一问一实验》？

《一问一实验》是爱可生开源社区的王牌专栏。每一期通过一个数据库问题对应一组实验的形式，简明易懂地讲解数据库基础知识。自 2020 年连载至今已发布 50 期，全网累计阅读量超 50 万。受到行业读者们的一致好评！真正成为了 DBA 们爱读、好读的技术内容。

《一问一实验：AI 版》全新归来，在 520 这个充满爱的特殊日子里，献上一份属于 DBA 们的爱（AI）。

专栏作者采访

问题：为什么会断更这么久？

黄炎：冠冕堂皇地说，就是被其他更好玩的事情吸引了兴趣。大模型的突破 在技术生产力上提供了巨大的可能性，对这些可能性的探索占用了非常多的时间。<br><br>所幸我们找到了将 AI 和专栏合并发展的方式：我们在公司内部建立了 ChatDBA（给 DBA 用的智能辅助系统，负责辅助 DBA 进行故障诊断处理等工作）来协助日常工作；从第 51 期开始，专栏的主要作者更换成了 ChatDBA，并由人类专家对专栏质量进行点评。

问题：会给读者们带来什么新的体验？

黄炎：ChatDBA 使用了多种常见和不常见的技术（它不单纯是 LLM+RAG），这个复杂的结构主要想让 ChatDBA 脱离**“搜索引擎”**这个功能层次。在故障诊断处理中 **能进行引导/指导、对知识的使用更精确、思考模式更“人化”。**我们希望由 AI 续写的专栏跟人类专家写的专栏没有差异（包括技术逻辑的正确性, 知识内容的详略程度, "人化"程度等方面）。<br><br>不过，目前 ChatDBA 还处于初级阶段，不能立马达到我的预期。

问题：这次的 AI 版和之前的版本有什么区别？

黄炎：随着 ChatDBA 后续的迭代，专栏的内容会逐渐产生一些变化。比如：

• 单纯的故障诊断 -> 深度的原理解析

• 单纯的数据库级别的分析 -> 整合操作系统和网络等多方面知识

• 单纯的事实推理 -> 技术猜想+验证

• 单纯的解决问题 -> 形成工具

• 短链推理 -> 长链推理

• 现象推理 -> 源码解释

• ……<br><br>

这些变化都会依赖于大模型本身的逻辑能力提高（希望国内外的大模型公司推出技术逻辑性更强的模型），以及 ChatDBA 的架构进化。<br><br>希望在专栏中向大家提供更多好玩的知识。

下面让我们正式进入《一问一实验：AI 版》的第 51 期。

问题

在 MySQL 日志中发现有大量报错，可能是什么原因造成的？

报错信息：

2024-04-26 23:27:06 [ERROR] /data/3306/base/5.7.26/bin/mysqld: The table '/data/3306/tmp/#sql_3d157_11' is full2024-04-27 00:11:04 [ERROR] /data/3306/base/5.7.26/bin/mysqld: The table '/data/3306/tmp/#sql_3d157_1' is full

实验

1. 将问题丢给 ChatDBA

有了 ChatDBA 加持，遇到问题就先别自己费劲了，扔给 ChatDBA 先看看它怎么说？

左侧为流程分析画布，展示 ChatDBA 对此问题的排查逻辑；右侧为互动区域

从左边的画布区域和右侧的对话区域可知，造成该问题的原因可能有以下几点：

• 配置的临时表空间大小不足。

• 数据库中执行的 SQL 查询创建了大量临时表。

• 磁盘空间不足或资源限制。

接下来我们根据 ChatDBA 的推荐的执行步骤查看一下相关配置。

2. ChatDBA 协助问题排查

首先，根据推荐的步骤检查参数的配置情况如何。

接下来，把从系统中查询到的配置信息提供给 ChatDBA。

在这里，ChatDBA 意识到日志表满的报错可能与这个配置有关，但是还不能具体确定，所以希望我们提供对应的临时表实际使用情况。通过 ChatDBA 给出的两条命令执行后可知 MySQL 的临时表空间（ibtmp1）实际已经占用了 50G。

可以看到，ChatDBA 大概率已经确认是参数配置导致的，但是同时也指出长事务、长查询这些才有可能是问题的真正原因。

最后，ChatDBA 给出的解决方案首先是优化对应的 SQL 语句，但是在当前的业务场景下无法直接修改 SQL，所以我们选择通过修改参数的方式来临时处理。

3. ChatDBA 给出解决方案

ChatDBA 提供了扩展临时表空间的具体步骤，执行调整 innodb_temp_data_file_path 参数的配置。

4. 实验总结

针对 2024-04-26 23:27:06 [ERROR] /data/3306/base/5.7.26/bin/mysqld: The table '/data/3306/tmp/#sql_3d157_11' is full 报错的问题，我们看到了三个排查方向：参数配置过小；磁盘空间不足；SQL 语句创建了大量的临时表。

ChatDBA 给出的解决方向是先看配置情况（在我们日常工作中也可以参考这个 case 的排查思路），先用查询的方法拿到配置信息快速定位问题，然后通过调整参数的方法临时解决问题，最后才是深度追踪问题的根源。

在这个 case 中是因为用户的业务场景中有大量的长事务、长查询存在，所以导致对临时表空间占用很高，需要配合业务方针对性的优化 SQL 语句才是解决此问题的最终办法。

问问 ChatGPT-4o

我们也将相同的问题送给了 ChatGPT-4o，让我们看看效果如何。

可以看到这类通用的大语言模型偏好是给用户一个大而全的内容，但是缺少具体的操作指向性与问题理解能力，导致用户在输入信息后没有办法很好的确定下一步应该做什么，从而真正的解决问题。

什么是 ChatDBA？