MySQL 8.4 參考手冊  /  一般資訊  /  如何回報錯誤或問題

1.6 如何回報錯誤或問題

在回報問題的錯誤報告之前,請先嘗試驗證它是否為錯誤,以及是否已回報過。

  • 首先在 https://mysqldev.dev.org.tw/doc/ 上搜尋 MySQL 線上手冊。我們會盡力保持手冊的更新,頻繁地更新新發現的問題的解決方案。此外,隨手冊附帶的發行說明可能特別有用,因為較新版本很有可能包含您問題的解決方案。發行說明可於手冊的上述網址取得。

  • 如果您在 SQL 陳述式中遇到剖析錯誤,請仔細檢查您的語法。如果您無法找出任何問題,則極有可能是您目前使用的 MySQL 伺服器版本不支援您正在使用的語法。如果您使用的是目前版本,且手冊中未涵蓋您正在使用的語法,則表示 MySQL 伺服器不支援您的陳述式。

    如果手冊涵蓋您正在使用的語法,但您使用的是較舊版本的 MySQL 伺服器,您應該查看 MySQL 變更歷史,以了解語法何時實作。在這種情況下,您可以選擇升級到較新版本的 MySQL 伺服器。

  • 如需一些常見問題的解決方案,請參閱 第 B.3 節,「問題和常見錯誤」

  • http://bugs.mysql.com/ 搜尋錯誤資料庫,以查看該錯誤是否已回報並修復。

  • 您也可以使用 https://mysql.dev.org.tw/search/ 來搜尋位於 MySQL 網站上的所有網頁(包括手冊)。

如果您在手冊、錯誤資料庫或郵件列表存檔中找不到答案,請諮詢您當地的 MySQL 專家。如果您仍然無法找到問題的答案,請使用下列準則回報錯誤。

回報錯誤的正常方式是造訪 http://bugs.mysql.com/,這是我們的錯誤資料庫位址。此資料庫是公開的,任何人都可以瀏覽和搜尋。如果您登入系統,則可以輸入新的報告。

http://bugs.mysql.com/ 的錯誤資料庫中發布的,並針對特定版本更正的錯誤,會在發行說明中註明。

如果您在 MySQL 伺服器中發現安全性錯誤,請立即發送電子郵件至 告知我們。例外情況:支援客戶應向 Oracle 支援回報所有問題,包括安全性錯誤,網址為 http://support.oracle.com/

若要與其他使用者討論問題,您可以使用 MySQL 社群 Slack

撰寫良好的錯誤報告需要耐心,但第一次就做對,可以節省我們和您自己的時間。一份良好的錯誤報告(包含錯誤的完整測試案例)可以讓我們很有可能在下一個版本中修復該錯誤。本節將協助您正確撰寫報告,以免您浪費時間做一些可能對我們沒有太大幫助的事情。請仔細閱讀本節,並確保您的報告中包含此處描述的所有資訊。

最好在發布之前,使用最新生產或開發版本的 MySQL 伺服器測試問題。任何人應該都能透過在您的測試案例上使用 mysql test < script_file,或執行您在錯誤報告中包含的 shell 或 Perl 指令碼來重現該錯誤。任何我們可以重現的錯誤,都很有可能在下一個 MySQL 版本中修復。

在錯誤報告中加入對問題的良好描述最有幫助。也就是說,提供一個好的範例來說明您所做的導致問題的所有動作,並以精確的細節描述問題本身。最好的報告是那些包含完整範例,顯示如何重現錯誤或問題的報告。請參閱 第 7.9 節,「除錯 MySQL」

請記住,我們有可能回應包含過多資訊的報告,但不可能回應包含過少資訊的報告。人們經常省略事實,因為他們認為自己知道問題的原因,並假設某些細節無關緊要。一個好的原則是,如果您對聲明某件事感到疑惑,請聲明它。在報告中多寫幾行比等待更久以獲得答案更快且更省事,如果我們必須要求您提供初始報告中遺漏的資訊。

錯誤報告中最常見的錯誤是 (a) 未包含您使用的 MySQL 發行版本的版本號碼,以及 (b) 未完整描述安裝 MySQL 伺服器的平台(包括平台類型和版本號碼)。這些是非常相關的資訊,在 100 次中有 99 次,沒有這些資訊的錯誤報告是無用的。我們經常收到類似 為什麼這個對我不起作用?的問題。然後我們發現所要求的功能並未在該 MySQL 版本中實作,或報告中描述的錯誤已在較新的 MySQL 版本中修復。錯誤通常與平台相關。在這種情況下,如果我們不知道作業系統和平台的版本號碼,我們幾乎不可能修復任何問題。

如果您是從原始碼編譯 MySQL,如果它與問題相關,也請記得提供有關編譯器的資訊。人們經常在編譯器中發現錯誤,並認為問題與 MySQL 相關。大多數編譯器一直在開發中,並且每個版本都變得更好。若要判斷您的問題是否取決於您的編譯器,我們需要知道您使用的編譯器。請注意,每個編譯問題都應視為錯誤並相應回報。

如果程式產生錯誤訊息,請務必在您的報告中包含該訊息。如果我們嘗試從存檔中搜尋某些內容,最好是報告的錯誤訊息與程式產生的訊息完全相符。(甚至大小寫都應該遵守。)最好將整個錯誤訊息複製並貼到您的報告中。您絕不應該嘗試從記憶中重現訊息。

如果您在使用 Connector/ODBC (MyODBC) 時遇到問題,請嘗試產生追蹤檔案並與您的報告一起寄出。請參閱 如何回報 Connector/ODBC 問題或錯誤

如果您的報告包含從您使用 mysql 命令列工具執行的測試案例中產生的長查詢輸出,您可以使用 --vertical 選項或 \G 語句終止符,使輸出更易於閱讀。本節稍後的 EXPLAIN SELECT 範例示範了如何使用 \G

請在您的報告中包含以下資訊:

  • 您正在使用的 MySQL 發行版本號(例如,MySQL 5.7.10)。您可以透過執行 mysqladmin version 來找出您正在運行的版本。mysqladmin 程式可以在您的 MySQL 安裝目錄下的 bin 目錄中找到。

  • 您遇到問題的機器的製造商和型號。

  • 作業系統名稱和版本。如果您使用的是 Windows,通常可以透過雙擊「我的電腦」圖示並下拉「說明/關於 Windows」選單來取得名稱和版本號。對於大多數類 Unix 作業系統,您可以透過執行命令 uname -a 來取得此資訊。

  • 有時,記憶體(實體和虛擬)的大小是相關的。如有疑問,請包含這些值。

  • 您的 MySQL 安裝中的 docs/INFO_BIN 檔案的內容。此檔案包含有關 MySQL 如何配置和編譯的資訊。

  • 如果您使用的是 MySQL 軟體的原始碼發行版本,請包含您使用的編譯器的名稱和版本號。如果您使用的是二進位發行版本,請包含發行版本名稱。

  • 如果問題發生在編譯期間,請包含確切的錯誤訊息,以及錯誤發生所在檔案中違規程式碼周圍的幾行上下文。

  • 如果 mysqld 當機,您也應該報告導致 mysqld 意外退出的語句。通常,您可以透過啟用查詢日誌來執行 mysqld,然後在 mysqld 退出後查看日誌來取得此資訊。請參閱 第 7.9 節,「除錯 MySQL」

  • 如果資料庫表格與問題相關,請在錯誤報告中包含來自 SHOW CREATE TABLE db_name.tbl_name 語句的輸出。這是取得資料庫中任何表格定義的一種非常簡單的方法。這些資訊可以幫助我們建立與您所經歷的情況相符的環境。

  • 問題發生時生效的 SQL 模式可能很重要,因此請報告 sql_mode 系統變數的值。對於預存程序、預存函數和觸發器物件,相關的 sql_mode 值是建立物件時生效的值。對於預存程序或函數,SHOW CREATE PROCEDURESHOW CREATE FUNCTION 語句會顯示相關的 SQL 模式,或者您可以查詢 INFORMATION_SCHEMA 以取得該資訊。

    SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE
    FROM INFORMATION_SCHEMA.ROUTINES;

    對於觸發器,您可以使用此語句:

    SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODE
    FROM INFORMATION_SCHEMA.TRIGGERS;
  • 對於與效能相關的錯誤或 SELECT 語句的問題,您應始終包含 EXPLAIN SELECT ... 的輸出,以及 SELECT 語句產生的至少行數。您還應該包含每個涉及的表格的 SHOW CREATE TABLE tbl_name 的輸出。您提供的關於您情況的資訊越多,就越有可能有人能幫助您。

    以下是一個非常好的錯誤報告範例。這些語句是使用 mysql 命令列工具執行的。請注意,對於原本會提供難以閱讀的長輸出行的語句,使用了 \G 語句終止符。

    mysql> SHOW VARIABLES;
    mysql> SHOW COLUMNS FROM ...\G
           <output from SHOW COLUMNS>
    mysql> EXPLAIN SELECT ...\G
           <output from EXPLAIN>
    mysql> FLUSH STATUS;
    mysql> SELECT ...;
           <A short version of the output from SELECT,
           including the time taken to run the query>
    mysql> SHOW STATUS;
           <output from SHOW STATUS>
  • 如果在執行 mysqld 時發生錯誤或問題,請嘗試提供一個可重現異常的輸入腳本。此腳本應包含任何必要的原始檔。腳本越能接近重現您的情況,就越好。如果您可以建立一個可重現的測試案例,您應該將其上傳以附加到錯誤報告中。

    如果您無法提供腳本,您至少應該在報告中包含 mysqladmin variables extended-status processlist 的輸出,以提供有關您的系統效能的一些資訊。

  • 如果您無法產生只有幾行的測試案例,或者如果測試表格太大而無法包含在錯誤報告中(超過 10 行),您應該使用 mysqldump 轉儲您的表格,並建立一個 README 檔案來描述您的問題。使用 targzipzip 建立您檔案的壓縮封存檔。在您於 http://bugs.mysql.com/ 上啟動我們的錯誤資料庫的錯誤報告後,請按一下錯誤報告中的「檔案」標籤,以取得將封存檔上傳到錯誤資料庫的說明。

  • 如果您認為 MySQL 伺服器從某個語句產生了奇怪的結果,請不僅包含結果,還包括您認為的結果應該是什麼,以及說明您的意見基礎的解釋。

  • 當您提供問題範例時,最好使用您實際情況中存在的表格名稱、變數名稱等等,而不是想出新的名稱。問題可能與表格或變數的名稱有關。這些情況可能很少見,但還是安全為上。畢竟,對您來說,提供使用您實際情況的範例應該更容易,而且對我們來說絕對更好。如果您有不想在錯誤報告中顯示給其他人的資料,您可以使用「檔案」標籤上傳,如先前所述。如果資訊真的非常機密,您甚至不想向我們展示,請繼續提供使用其他名稱的範例,但請將此視為最後的選擇。

  • 如果可能,請包含給相關程式的所有選項。例如,指出您在啟動 mysqld 伺服器時使用的選項,以及您用來執行任何 MySQL 用戶端程式的選項。mysqldmysql 等程式以及 configure 腳本的選項通常是解決問題的關鍵,而且非常相關。包含它們絕不是壞主意。如果您的問題涉及以 Perl 或 PHP 等語言編寫的程式,請包含語言處理器的版本號,以及程式使用的任何模組的版本。例如,如果您有一個使用 DBIDBD::mysql 模組的 Perl 腳本,請包含 Perl、DBIDBD::mysql 的版本號。

  • 如果您的問題與權限系統有關,請包含 mysqladmin reload 的輸出,以及您在嘗試連線時收到的所有錯誤訊息。當您測試您的權限時,您應該執行 mysqladmin reload version 並嘗試使用給您帶來麻煩的程式連線。

  • 如果您有錯誤的修補程式,請務必包含它。但請不要假設修補程式是我們需要的全部,或者如果您不提供一些必要的資訊(例如顯示您的修補程式修復的錯誤的測試案例),我們就可以使用它。我們可能會發現您的修補程式有問題,或者我們可能根本不了解它。如果這樣,我們就無法使用它。

    如果我們無法驗證修補程式的確切用途,我們將不會使用它。測試案例在這裡可以幫助我們。證明修補程式可以處理所有可能發生的情況。如果我們發現一個修補程式不起作用的邊界情況(甚至是罕見的情況),它可能就沒有用處了。

  • 關於錯誤是什麼、為什麼會發生或它依賴於什麼的猜測通常是錯誤的。即使是 MySQL 團隊,如果不先使用除錯器來確定錯誤的真正原因,也無法猜測這些事情。

  • 在您的錯誤報告中指出您已檢查參考手冊和郵件封存,以便其他人知道您已嘗試自己解決問題。

  • 如果您的資料似乎已損壞,或在存取特定表格時收到錯誤,請先使用 CHECK TABLE 檢查您的表格。如果該語句報告任何錯誤

    • InnoDB 當機復原機制會在伺服器在被強制關閉後重新啟動時處理清除,因此在典型操作中不需要「修復」表格。如果您在 InnoDB 表格中遇到錯誤,請重新啟動伺服器,看看問題是否仍然存在,或者錯誤是否僅影響了記憶體中的快取資料。如果資料在磁碟上損壞,請考慮啟用 innodb_force_recovery 選項重新啟動,以便您可以轉儲受影響的表格。

    • 對於非交易式表格,請嘗試使用 REPAIR TABLEmyisamchk 來修復它們。請參閱第 7 章,MySQL 伺服器管理

    如果您使用的是 Windows,請使用 SHOW VARIABLES LIKE 'lower_case_table_names' 陳述式來驗證 lower_case_table_names 的值。此變數會影響伺服器如何處理資料庫和表格名稱的大小寫。其針對特定值的影響應如第 11.2.3 節,「識別碼大小寫敏感度」中所述。

  • 如果您經常遇到表格損毀的情況,您應該嘗試找出何時以及為何會發生這種情況。在這種情況下,MySQL 資料目錄中的錯誤日誌可能會包含一些有關發生情況的資訊。(這是名稱中帶有 .err 後綴的檔案。)請參閱第 7.4.2 節,「錯誤日誌」。請在您的錯誤報告中包含此檔案中的任何相關資訊。正常情況下,如果 mysqld 在更新過程中沒有被中途強制關閉,則絕對不會損毀表格。如果您可以找出導致 mysqld 當機的原因,我們就更容易為您提供問題的修復程式。請參閱第 B.3.1 節,「如何判斷問題的原因」

  • 如果可以,請下載並安裝最新版本的 MySQL 伺服器,並檢查它是否解決了您的問題。所有版本的 MySQL 軟體都經過徹底測試,應該可以正常運作。我們相信盡可能地實現向下相容性,您應該可以毫無困難地切換 MySQL 版本。請參閱第 2.1.2 節,「要安裝哪個 MySQL 版本和發行版」