原標題：ChatGPT vs. MySQL DBA Challenge
作者：Vinicius Grippa
責編&翻譯：宇亭
頭圖設計：Yeekin
隨著 ChatGPT 在解決人類問題方面愈加普及，我決定深入了解當前人工智能的現(xiàn)狀。盡管數(shù)據(jù)庫工程師們信賴這個工具，但像 StackOverflow 這樣的網(wǎng)站卻禁用了 ChatGPT。這讓人不由得擔心，我的職業(yè)（MySQL DBA）是否會由于人工智能的崛起而面臨“滅絕”的風險？ 正如我的導師在我剛開始在科技領域工作時所說的那樣，答案是：視情況而定。那么就目前的情況來看，我的答案是一個大大的否定。正如我們馬上要看到的，這些（ChatGPT 給出的）答案大部分比較泛泛而談、略顯一般，但至少是朝著正確的方向。然而，我也很清楚，沒有什么能夠阻止這些人工智能模型變得更加智能并提供更精確的答案。
接下來，讓我們來看看我曾經(jīng)在 MySQL DBA 面試中被問到的一些問題。
問題、回答、點評
問題1： 我有一臺MySQL服務器，擁有500GB的RAM；我的數(shù)據(jù)集僅為100GB。我的InnoDB緩沖池需要有多大？
ChatGPT： InnoDB 緩沖池用于將 MySQL 經(jīng)常訪問的數(shù)據(jù)緩存到內(nèi)存中。建議將緩沖池大小設置為足以容納整個數(shù)據(jù)集的值。由于您的數(shù)據(jù)集僅為 100GB，而服務器內(nèi)存為 500GB，因此可以將可用內(nèi)存中的相當一部分分配給 InnoDB 緩沖池。常見的緩沖池大小建議為可用內(nèi)存的 50% 到 75%。在您的情況下，緩沖池大小約為375GB（500GB的75%）應該是一個很好的起點。然而，您應該使用的實際值將取決于您的工作負載的具體特征。請注意，設置緩沖池大小過高可能會導致服務器上的其他進程爭奪內(nèi)存，從而影響性能。定期監(jiān)控服務器的內(nèi)存使用情況也很重要，以確保緩沖池沒有耗盡服務器的內(nèi)存資源。
點評： 所以這個回答既不準確又含糊其辭。由于我的數(shù)據(jù)集是100GB，我希望 ChatGPT 明確提到100GB是一個好的起點。如果我們更加深入地探討緩存的概念，那么當工作集（熱數(shù)據(jù)）較小時，緩沖池甚至可以更小。
問題2： 我有一個 MySQL 服務器，我的應用程序在我的 redo 日志中以100 MB/小時的速度寫入。我的 innodb_redo_log_capacity 需要多大?
ChatGPT: innodb_redo_log_capacity 參數(shù)指定了 InnoDB redo日志緩沖區(qū)的最大大小，用于在寫入磁盤之前存儲對數(shù)據(jù)庫所做的更改。redo 日志緩沖區(qū)的大小應足夠大，以處理在更改寫入磁盤所需的時間內(nèi)可能發(fā)生的最大更改量。要計算所需的 redo 日志緩沖區(qū)大小，可以使用以下公式：
innodb_redo_log_capacity =
(max_rate_of_change * max_redo_log_write_time) / redo_log_block_size
在您的情況下，您已提供了最大更改速率，即每小時100 MB。您需要估計寫入更改到磁盤所需的最大時間和 redo 日志塊大小。假設 redo 日志塊大小為 512 字節(jié)（這是innodb_log_block_size的默認值），并且將更改寫入磁盤所需的最大時間為 10 分鐘（0.16667小時），則計算如下：[...]
點評： 我故意沒有貼出完整答案，因為它非常錯誤。innodb_redo_log_capacity 是MySQL 服務器的一個設置，而 innodb_log_block_size 是 MariaDB 的一個設置。此外，redo 日志的容量并不等同于 redo 日志緩沖區(qū)，因此混淆了不同的技術和概念。如果你想了解如何計算良好的 redo 日志大小，請查閱這篇博客文章：
MySQL 8.0 Dynamic Redo Log Sizing
https://www.percona.com/blog/mysql-8-0-dynamic-redo-log-sizing/
問題3.1 ：
在我的 MySQL 服務器有以下表：
CREATE TABLE `joinit` (
`i` int(11) NOT NULL AUTO_INCREMENT,
`s` varchar(64) DEFAULT NULL,
`t` time NOT NULL,
`g` int(11) NOT NULL,
PRIMARY KEY (`i`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
問題3.2：
我該如何優(yōu)化以下查詢？
SELECT * FROM joinit WHERE g = 10;
ChatGPT： 為了優(yōu)化SELECT * FROM joinit WHERE g = 10;的查詢，您可以按照以下步驟進行：
在 g 列上添加索引：由于查詢是通過 g 列進行過濾的，因此在該列上添加索引將提高查詢性能。您可以使用以下命令添加索引：
ALTER TABLE joinit ADD INDEX (g)
[...]
點評： 答案中還有一些注釋，但ChatGPT給出的第一個答案是 “ADD INDEX” 命令，這一事實令人印象深刻~
問題4： 我有一臺安裝了 MySQL 數(shù)據(jù)庫的服務器，它有 10 個 CPU。我應該將 innodb_thread_concurrency 設置為多少才合適呢？
ChatGPT: MySQL 中 innodb_thread_concurrency 的理想值取決于幾個因素，包括服務器的工作負載、CPU 內(nèi)核數(shù)量和可用內(nèi)存量。通常情況下，在具有 10 個 CPU 的服務器上，推薦的 innodb_thread_concurrency 值通常在 16 到 32 之間。然而，需要注意的是，最佳值可能會因具體工作負載和硬件配置而有所不同。要確定服務器的理想值，可以將 innodb_thread_concurrency 值設置為中等值（例如 16），然后監(jiān)視服務器的性能。然后可以逐漸增加或減少該值，根據(jù)負載來優(yōu)化服務器性能。[...]
點評： 這里的回答遵循了一個經(jīng)驗法則。如果您對此設置有更多的細節(jié)興趣，可以查看以下博客文章：
InnoDB Thread Concurrency
https://www.percona.com/blog/innodb-thread-concurrency/
此外，在審查此博客文章時，我的一個同事對這個回答并不滿意（這很棒！）。他說：
實際上，在一個10核心的服務器中，16到32可能會導致上下文切換爭用，因此IMO的數(shù)字是不正確的，一個好的起點是設置一個比CPU數(shù)量小的數(shù)字。因此，實際答案高度依賴于工作負載(即并發(fā)線程運行、查詢持續(xù)時間等)。
正如我們所看到的，決策并不僅僅基于公式或文檔。很多知識都依賴于經(jīng)驗和在解決問題時所學到的教訓。 此外，與其他工程師的辯論允許您收集其他觀點，從而將解決方案改進到 ChatGPT 無法達到的程度。
現(xiàn)在讓我們把難度升級一下。
問題5： 如何在 MySQL 中為我的空間索引刷新統(tǒng)計信息?
ChatGPT: 在 MySQL 中，您可以使用 ANALYZE TABLE 語句來刷新空間索引的統(tǒng)計信息。[...]
點評： 但是這個回答是錯誤的。只有當重建表時空間索引的統(tǒng)計信息才會被刷新。此外，還存在一個文檔記錄的 bug:
OPTIMIZE TABLE 未對 R-樹索引進行排序，例如 POINT 列上的空間索引。（Bug #23578）
問題6.1： 我在 Ubuntu 22.04 中安裝了 MySQL 8，并將我的 datadir 移動到另一個位置。我已在 my.cnf 文件中調(diào)整了我的 datadir，但我的數(shù)據(jù)庫無法啟動?？赡苁鞘裁丛?？
ChatGPT： 如果您已將 MySQL 數(shù)據(jù)目錄移到另一個位置并更新了 my.cnf 配置文件中的 datadir 參數(shù)，但 MySQL 仍無法啟動，則可能需要更新其他配置參數(shù)。[...]
點評： 這里的答案是泛泛而談的。但是，如果我修改我的問題可以使其更準確：
問題6.2： 我在Ubuntu 22.04上安裝了MySQL 8，并將我的datadir移動到了另一個位置。我在my.cnf文件中調(diào)整了我的datadir，但是我的數(shù)據(jù)庫沒有啟動。datadir 是正確的。可能是什么問題？
點評： 然后我得到了一個更合理的答案：
ChatGPT： 如果數(shù)據(jù)目錄正確并且MySQL錯誤日志文件中沒有錯誤，那么新數(shù)據(jù)目錄的文件權限可能沒有正確設置。[...]
問題7.1： 我有以下 iostat 示例：
2020_10_06_14_22_25-iostat:Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
2020_10_06_14_21_55-iostat:sda 2.32 0.84 386.08 1004.05 5570.21 7514.67 18.83 4.45 12.05 0.79 1.14 0.49 8.16
2020_10_06_14_21_55-iostat:sda 0.00 0.00 113.00 1535.00 1808.00 13727.50 18.85 1.61 10.98 0.93 0.98 0.42 8.40
2020_10_06_14_21_55-iostat:sda 0.00 1.00 79.00 1494.00 1264.00 7203.00 10.77 2.04 20.66 0.65 0.67 0.45 1.30
2020_10_06_14_21_55-iostat:sda 0.00 0.00 132.00 1500.00 2112.00 14508.50 20.37 5.87 30.15 0.68 1.19 0.47 6.10
問題7.2： 我是否遇到了 I/O 問題?
ChatGPT： 要確定是否遇到了 I/O 問題，您需要分析 %util 列。此列顯示磁盤在采樣期間繁忙狀態(tài)的時間百分比。較高的 %util 值表示磁盤大部分時間都處于繁忙狀態(tài)，這可能表明存在 I/O 瓶頸。在您的樣本中，%util 值在 1.30 到 8.40 之間，這些是相對較低的值，不一定表示有 I/O 問題。
點評： ****這個答案有待改進。該答案未考慮隊列或樣本的延遲，這可能表明磁盤有問題。基本上，ChatGPT 只考慮 %util 列來得出答案。
問題8： 我有一個2個NUMA核心的服務器。 我可以在我的Percona Server中使用哪個設置來更好地使用內(nèi)存？
ChatGPT： 如果您有一個有 2 個 NUMA 核心的服務器，則可以在 Percona Server 中使用 numa-interleave 選項來改善內(nèi)存使用情況。[...]
點評： 這個答案僅適用于較舊版本的 Percona Server。現(xiàn)在，您可以使用 innodb_numa_interleave。我認為將其添加到這里是相關的（可不是為了打廣告），因為我們可以看到，用于供 AI 訓練的數(shù)據(jù)集需要不斷刷新才能提供相關的答案。
總結(jié)
ChatGPT 提供的答案是準確的，但通常會提供過于泛泛的信息，這些信息可能無法幫助我們解決具體的問題。此外，ChatGPT使用的數(shù)據(jù)集非常重要，因為我們可能會收到過時或誤導性的信息。我們不能盲目地接受答案，而應該檢查答案的正確性，這要求我們事先了解這個領域的知識。
但是，ChatGPT 可以為那些剛開始學習 MySQL 和 Linux 的人提供一個很好的起點。
很多人可能會說，我需要提供精確的問題才能獲得所需的答案。這是正確的。然而，在與我們的客戶合作時，大多數(shù)緊急情況下，他們唯一掌握的信息就是應用程序運行緩慢或無法連接到數(shù)據(jù)庫。因此，在現(xiàn)實世界中，如果不是數(shù)據(jù)庫專家，提出精確的問題是很困難的。能夠知道正確的問題是找到正確答案的一半。作為這篇文章的結(jié)尾，我問了 ChatGPT 的最后一個問題：
問題9： ChatGPT 會取代 MySQL DBA 的工作嗎？
答案： 不會。ChatGPT是由OpenAI開發(fā)的AI語言模型，不是為了取代MySQL DBA的工作而設計的。雖然ChatGPT可以在MySQL相關問題的一定程度上提供幫助和指導，但它不能替代MySQL DBA的知識、專業(yè)技能和決策能力。MySQL DBA負責維護、保護和優(yōu)化MySQL數(shù)據(jù)庫系統(tǒng)，這涉及到復雜的任務和決策過程，需要人類專業(yè)知識和經(jīng)驗。
因此，目前我們是安全的 ??！
不開玩笑了，也請不要擔心。我認為科學技術的設計與進步并非為了取代我們，而是要幫助我們更加高效地完成任務，以便將更多的時間投入到真正為客戶創(chuàng)造價值的工作中。 我對未來充滿信心和興奮，期待接下來會發(fā)生什么！
本文中 ChatGPT 使用的模型為 GPT-3.5
