🥳 社區王牌專欄《一問一實驗：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 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？
更多技術文章，請訪問：https://opensource.actionsky.com/
關於 SQLE
SQLE 是一款全方位的 SQL 質量管理平臺，覆蓋開發至生產環境的 SQL 審覈和管理。支持主流的開源、商業、國產數據庫，爲開發和運維提供流程自動化能力，提升上線效率，提高數據質量。