🥳 社区王牌专栏《一问一实验：AI 版》全新归来，在 520 这个充满爱的特殊日子里，献上一份属于 DBA 们的爱（AI）。
什么是《一问一实验》？
《一问一实验》是爱可生开源社区的王牌专栏。每一期通过一个数据库问题对应一组实验的形式，简明易懂地讲解数据库基础知识。自 2020 年连载至今已发布 50 期，全网累计阅读量超 50 万。受到行业读者们的一致好评！真正成为了 DBA 们爱读、好读的技术内容。
《一问一实验：AI 版》全新归来，在 520 这个充满爱的特殊日子里，献上一份属于 DBA 们的爱（AI）。
专栏作者采访
问题：为什么会断更这么久？
黄炎：冠冕堂皇地说，就是被其他更好玩的事情吸引了兴趣。大模型的突破 在技术生产力上提供了巨大的可能性，对这些可能性的探索占用了非常多的时间。
所幸我们找到了将 AI 和专栏合并发展的方式：我们在公司内部建立了 ChatDBA（给 DBA 用的智能辅助系统，负责辅助 DBA 进行故障诊断处理等工作）来协助日常工作；从第 51 期开始，专栏的主要作者更换成了 ChatDBA，并由人类专家对专栏质量进行点评。
问题：会给读者们带来什么新的体验？
黄炎：ChatDBA 使用了多种常见和不常见的技术（它不单纯是 LLM+RAG），这个复杂的结构主要想让 ChatDBA 脱离“搜索引擎”这个功能层次。在故障诊断处理中 能进行引导/指导、对知识的使用更精确、思考模式更“人化”。我们希望由 AI 续写的专栏跟人类专家写的专栏没有差异（包括技术逻辑的正确性, 知识内容的详略程度, “人化”程度等方面）。
不过，目前 ChatDBA 还处于初级阶段，不能立马达到我的预期。
问题：这次的 AI 版和之前的版本有什么区别？
黄炎：随着 ChatDBA 后续的迭代，专栏的内容会逐渐产生一些变化。比如：
- 单纯的故障诊断 -> 深度的原理解析
- 单纯的数据库级别的分析 -> 整合操作系统和网络等多方面知识
- 单纯的事实推理 -> 技术猜想+验证
- 单纯的解决问题 -> 形成工具
- 短链推理 -> 长链推理
- 现象推理 -> 源码解释
- ……
这些变化都会依赖于大模型本身的逻辑能力提高（希望国内外的大模型公司推出技术逻辑性更强的模型），以及 ChatDBA 的架构进化。
希望在专栏中向大家提供更多好玩的知识。
下面让我们正式进入《一问一实验：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 full
2024-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？
