正式發布之前，每個MySQL版本均在很多平台上進行了測試。這不表示MySQL中不存在缺陷，但是，如果存在缺陷，它們應很少，而且很難發現。如果你遇到問題，如果你嘗試找出導致系統崩潰的准確原因，這始終很有幫助，這是因為，如果這樣的話，快速解決問題的機會很大。
首先，應嘗試找出問題是否與mysqld服務器有關，或是否與客戶端有關。通過執行mysqladmin version，可檢查mysqld服務器運行了多長時間。如果MySQLd宕機並重啟，應查看服務器的錯誤日志以找出原因。
在某些系統上，在錯誤日志中，可發現MySQLd宕機的堆棧跟蹤，可使用resolve_stack_dump程序解決它。
注意，錯誤日志中的變量值並非始終是100％正確的。
很多服務器崩潰是因損壞的數據文件或索引文件而導致的，每次執行完SQL語句之後並在向客戶端通告結果之前，MySQL將使用write()系統調用更新磁盤上的文件（如果你使用了“--delay-key-write”選項，情況並非如此，此時將寫入數據文件而不是索引文件）。這意味著，即使mysqld崩潰，數據文件的內容也是安全的，這是因為操作系統能保證將未刷新的數據寫入磁盤。使用“--flush”選項啟動mysqld，這樣，每次執行完SQL語句後，可強制MySQL將所有內容寫入磁盤。
前述介紹表明，在正常情況下不會出現損壞的表，除非出現了下述情況之一：
在更新過程中，MySQL服務器或服務器主機被停止。
你發現了mysqld中存在的1個缺陷，該缺陷導致MySQLd在更新中途中止。
在MySQLd操作的同時，某些外部程序正在操控數據文件或索引文件，未恰當鎖定表。
你正使用系統上的相同數據目錄運行很多MySQLd服務器，該系統不支持良好的文件系統鎖定（通常是由lockd鎖定管理器負責的），或使用“--skip-external-locking”選項運行了多個服務器。
崩潰的數據文件或索引文件，其中包含導致MySQLd混亂的損壞很嚴重的數據。
在數據存儲節點發現缺陷。這種可能性不大，但至少是可能的。在該情況下，可在修復的表副本上，通過使用ALTER TABLE，嘗試將表類型更改為另一種存儲引擎。
由於很難得知為什麼某事會出現崩潰，首先請檢查用於其他方面的事項是否崩潰。請嘗試采取下述措施：
用mysqladmin shutdown停止mysqld服務器，從數據目錄運行myisamchk --silent --force */*.MYI，檢查所有的MyISAM表，並重啟MySQLd。這樣，就能確保從干淨的狀態運行服務器。
使用“--log”選項啟動mysqld，並根據寫入日志的信息確定是否某些特殊的查詢殺死了服務器。約95%的缺陷與特定的查詢有關。正常情況下，這是服務器重啟前日志文件中最夠數個查詢中的1個。如果能夠用特殊查詢重復殺死MySQL，即使在發出查詢前檢查了所有表的情況下也同樣，那麼你就應能確定缺陷，並應提交關於該缺陷的缺陷報告。
嘗試提供一個測試范例，我們應能利用該范例重復問題。
請在mysql-test目錄下並根據MySQL基准進行測試。它們能相當良好地測試MySQL。你也可以為基准測試增加代碼，以模擬你的應用程序。基准測試可在源碼分發版的sql-bench目錄下找到，對於二進制分發版，可在MySQL安裝目錄下的sql-bench目錄下找到。
嘗試使用fork_big.pl腳本（它位於源碼分發版的測試目錄下）。
如果你將MySQL配置為調試模式，如果某事出錯，可更為容易地搜集關於可能錯誤的信息。如果將MySQL配置為調試模式，可生成1個安全的內存分配程序，可使用它發現某些錯誤。此外，它還提供了很多輸出，這類輸出與出現的問題相關。在configure上使用“--with-debug”或“--with-debug=full”選項重新配置MySQL，然後再編譯它。
確保為你的操作系統應用了最新的補丁。
對mysqld使用“--skip-external-locking”選項。在某些系統上，lockd鎖定管理器不能正確工作，“--skip-external-locking”選項通知mysqld不使用外部鎖定。（這意味著，你不能在相同的數據目錄上運行2個MySQLd服務器，如果使用myisamchk，必須謹慎。然而，嘗試將該選項用作測試也是有益的）。
當mysqld看上去正在運行但並未響應時，是否運行了mysqladmin -u root processlist？某些時候，即使你認為mysqld處於閒置狀態時，實際情況並非如此。問題可能是因為所有連接均已使用，或存在某些內部鎖定問題。即使在該情況下，MySQLadmin -u root processlist通常能夠進行連接，並能提供關於當前連接數以及其狀態的有用信息。
在運行其他查詢的同時，在單獨的窗口中運行命令mysqladmin -i 5 status或MySQLadmin -i 5 -r status，以生成統計信息。
嘗試采用下述方法：
從gdb（或另一個調試器）啟動MySQLd。
運行測試腳本。
在3個較低層面上輸出backtrace（向後跟蹤）和局部變量。在gdb中，當MySQLd在gdb內崩潰時，可使用下述命令完成該任務：
backtrace info local up info local up info local
使用gdb，你還能檢查與info線程共存的線程，並切換至特定的線程N，其中，N是線程ID。
嘗試用Perl腳本模擬你的應用程序，強制MySQL崩潰或行為異常。
發送正常的缺陷報告。
應比通常的報告更詳細。由於MySQL是為很多人提供服務的，它可能因僅存在於你的計算機上的某事崩潰（例如，與你的特定系統庫有關的錯誤）。
如果你遇到與包含動態長度行的表有關的問題，而且你僅使用VARCHAR列（而不是BLOB或TEXT列），可嘗試用ALTER TABLE將所有VARCHAR列更改為CHAR列。這樣，就會強制MySQL使用固定大小的行。固定大小的行占用的空間略多，但對損壞的容忍度更高。
目前的動態行代碼在MySQL AB已使用多年，很少遇到問題，但從本質上看，動態長度行更傾向於出現錯誤，因此，不妨嘗試采用該策略以查看它是否有幫助，這不失為一個好主意。
診斷問題時不要將你的服務器硬件排除在外。有缺陷的硬件能夠導致數據損壞。對硬件進行故障診斷與排除操作時，尤其應注意RAM和硬盤驅動器。
