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

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 伺服器中發現安全性錯誤,請立即傳送電子郵件訊息至 通知我們。例外情況:支援客戶應透過 http://support.oracle.com/ 向 Oracle 支援回報所有問題,包括安全性錯誤。

若要與其他使用者討論問題,您可以使用 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 等語言編寫的程式,請包含語言處理器的版本號碼,以及程式使用的任何模組的版本。例如,如果您的 Perl 腳本使用 DBIDBD::mysql 模組,請包含 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 版本和發行版本」