Windows Server 2008 R2 x64

MySQL 伺服器 5.6.14 x64

是否有其他人在某些表在 Microsoft Windows 伺服器上被標記為崩潰時遇到問題？我們有幾台 Windows 伺服器（不是選擇）和六台執行 MySQL 的 Linux 伺服器。出於某種原因，Windows 伺服器上的表經常被標記為“崩潰”。在我們的 Linux (Ubuntu) 伺服器上，我們從來沒有遇到過這些問題。

2014-01-23 10:11:42 1868 [ERROR] MySQL: Table '.\elite_prod\ffcont' is marked as crashed and should be repaired
2014-01-23 10:11:42 1868 [ERROR] MySQL: Table '.\elite_prod\bldr' is marked as crashed and should be repaired
2014-01-23 10:11:43 1868 [ERROR] MySQL: Table '.\elite_prod\frtfwd' is marked as crashed and should be repaired
2014-01-23 10:11:44 1868 [ERROR] MySQL: Table '.\elite_prod\histry' is marked as crashed and should be repaired

似乎我們必須每隔幾週左右處理一次這個問題。非常令人沮喪。

從錯誤消息中，我可以快速告訴以下內容：

• 數據庫是elite_prod
• ffcount, bldr, frtfwd, 和histry都是 MyISAM 表

因為您使用的是MyISAM 儲存引擎，所以您有兩個主要障礙：

讓分 #1

對 MyISAM 的更改以不同方式記憶體（與作業系統無關）

• MyISAM 表的索引頁記憶體在 MyISAM 密鑰緩衝區中（大小為key_buffer_size）

• 索引更改.MYI由 MyISAM 儲存引擎刷新到

• 數據永遠不會被記憶體，因為沒有以引擎為中心的數據緩衝

• 數據更改.MYD由作業系統刷新（哎喲！！！！）

• 我之前討論過這個

  • InnoDB 和 MyISAM 之間的主要區別是什麼？
  • 由於系統崩潰而回滾的插入查詢很少
  • 我的數據庫在啟動時不斷崩潰，如何在不執行的情況下修復它？

讓分 #2

Microsoft Windows 在記憶體磁碟更改方面很糟糕。即使FLUSH TABLES;在 Windows 環境中執行 MySQL 也不是萬能的。恕我直言，任何使用 PostgreSQL 或 Oracle 的人都應該能夠對 Windows 提出同樣的抱怨。我將把它留給 SQL Server 專家來回答他們如何根據 SQL Server 找到 Windows 記憶體。

分析

MyISAM 針對錶維護打開文件句柄的計數。

如果 mysqld 程序或 Windows Server 崩潰，每個具有打開文件句柄的 MyISAM 將在內部保留打開文件句柄計數。

當您自 mysqld 啟動以來第一次訪問 MyISAM 表時，它應該有一個零文件句柄。否則，您會收到該錯誤消息marked as crashed and should be repaired。這解釋了表在崩潰時定期出現。

請參閱我的文章MyISAM 表不斷崩潰。我有哪些選擇？

建議

您可以將這些表切換到 InnoDB 並讓 InnoDB 緩衝區記憶體所有內容，或者至少更好地記憶體。在這方面我仍然會擔心 Windows，因為在 Windows 版本的 MySQL 中禁用了選項innodb_flush_method 。我說禁用是因為MySQL 文件說：

控制用於將數據刷新到 InnoDB 數據文件和日誌文件的系統呼叫，這會影響 I/O 吞吐量。此變數僅與 Unix 和 Linux 系統相關。在 Windows 系統上，flush 方法始終是 async_unbuffered 且無法更改。

如果您想將表保留為 MyISAM，請返回 Ubuntu，因為在刷新磁碟更改時它會更加勤奮，尤其是當它有足夠的 RAM 時。對於 Windows 中的 MyISAM 表，即使是 TB 的 RAM 也無濟於事。

引用自：https://dba.stackexchange.com/questions/57393