Table 'content_tags' is marked as crashed and should be repaired
這樣的錯誤
問題分析：
出現這個提示，說明 ‘%s ’ 表損壞，可能是非正常關機造成的，需要修復一下就可以了。
解決方法：
REPAIR TABLE `<span style="font-family: Arial, Helvetica, sans-serif;">content_tags</span>`
也可以用myisamchk 來修復。
初步估計可能是索引重建的時候除了問題，
至此，問題解決！
PS：一些其他問題收集
階段1 ：檢查你的表
如果你有很多時間，運行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）選項禁止不必要的信息。
如果mysqld 服務器處於宕機狀態，應使用--update-state 選項來告訴myisamchk 將表標記為' 檢查過的' 。
你必須只修復那些myisamchk 報告有錯誤的表。對這樣的表，繼續到階段2 。
如果在檢查時，你得到奇怪的錯誤( 例如out of memory 錯誤) ，或如果myisamchk 崩潰，到階段3 。
階段2 ：簡單安全的修復
注釋：如果想更快地進行修復，當運行myisamchk 時，你應將sort_buffer_size 和Key_buffer_size 變量的值設置為可用內存的大約25% 。
首先，試試myisamchk -r -q tbl_name(-r -q 意味著“ 快速恢復模式”) 。這將試圖不接觸數據文件來修復索引文件。如果數據文件包含它應有的一切內容和指向數據文件內正確地點的刪除連接，這應該管用並且表可被修復。開始修復下一張表。否則，執行下列過程：
在繼續前對數據文件進行備份。
使用myisamchk -r tbl_name(-r 意味著“ 恢復模式”) 。這將從數據文件中刪除不正確的記錄和已被刪除的記錄並重建索引文件。
如果前面的步驟失敗，使用myisamchk --safe-recover tbl_name 。安全恢復模式使用一個老的恢復方法，處理常規恢復模式不行的少數情況( 但是更慢) 。
如果在修復時，你得到奇怪的錯誤( 例如out of memory 錯誤) ，或如果myisamchk 崩潰，到階段3 。
階段3 ：困難的修復
只有在索引文件的第一個16K 塊被破壞，或包含不正確的信息，或如果索引文件丟失，你才應該到這個階段。在這種情況下，需要創建一個新的索引文件。按如下步驟操做：
把數據文件移到安全的地方。
使用表描述文件創建新的( 空) 數據文件和索引文件：
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit
如果你的MySQL 版本沒有TRUNCATE TABLE ，則使用DELETE FROM tbl_name 。
將老的數據文件拷貝到新創建的數據文件之中。（不要只是將老文件移回新文件之中；你要保留一個副本以防某些東西出錯。）
回到階段2 。現在myisamchk -r -q 應該工作了。（這不應該是一個無限循環）。
你還可以使用REPAIR TABLE tbl_name USE_FRM ，將自動執行整個程序。
階段4 ：非常困難的修復
只有.frm 描述文件也破壞了，你才應該到達這個階段。這應該從未發生過，因為在表被創建以後，描述文件就不再改變了。
從一個備份恢復描述文件然後回到階段3 。你也可以恢復索引文件然後回到階段2 。對後者，你應該用myisamchk -r 啟動。
如果你沒有進行備份但是確切地知道表是怎樣創建的，在另一個數據庫中創建表的一個拷貝。刪除新的數據文件，然後從其他數據庫將描述文件和索引文件移到破壞的數據庫中。這樣提供了新的描述和索引文件，但是讓.MYD 數據文件獨自留下來了。回到階段2 並且嘗試重建索引文件。
InnoDB 表可以采用下面的方法修復：
如果數據庫頁被破壞，你可能想要用SELECT INTO OUTFILE 從從數據庫轉儲你的表，通常以這種方法獲取的大多數數據是完好的。即使這樣，損壞可能導致SELECT * FROM tbl_name 或者InnoDB 後台操作崩潰或斷言，或者甚至使得InnoDB 前滾恢復崩潰。 盡管如此，你可以用它來強制InnoDB 存儲引擎啟動同時阻止後台操作運行，以便你能轉儲你的表。例如：你可以在重啟服務器之前，在選項文件的[mysqld] 節添加如下的行：
[mysqld]innodb_force_recovery = 4innodb_force_recovery 被允許的非零值如下。一個更大的數字包含所有更小數字的預防措施。如果你能夠用一個多數是4 的選項值來轉儲你的表，那麼你是比較安全的，只有一些在損壞的單獨頁面上的數據會丟失。一個為6 的值更誇張，因為數據庫頁被留在一個陳舊的狀態，這個狀態反過來可以引發對B 樹和其它數據庫結構的更多破壞。
1 (SRV_FORCE_IGNORE_CORRUPT)
即使服務器檢測到一個損壞的頁，也讓服務器運行著；試著讓SELECT * FROM tbl_name 跳過損壞的索引記錄和頁，這樣有助於轉儲表。
2 (SRV_FORCE_NO_BACKGROUND)
阻止主線程運行，如果崩潰可能在淨化操作過程中發生，這將阻止它。
3 (SRV_FORCE_NO_TRX_UNDO)
恢復後不運行事務回滾。
4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入緩沖合並操作。如果你可能會導致一個崩潰。最好不要做這些操作，不要計算表統計表。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
啟動數據庫之時不查看未完成日志：InnoDB 把未完成的事務視為已提交的。
6 (SRV_FORCE_NO_LOG_REDO)
不要在恢復連接中做日志前滾。
數據庫不能另外地帶著這些選項中被允許的選項來使用。作為一個安全措施，當innodb_force_recovery 被設置為大於0 的值時，InnoDB 阻止用戶執行INSERT, UPDATE 或DELETE 操作.
即使強制恢復被使用，你也可以DROP 或CREATE 表。如果你知道一個給定的表正在導致回滾崩潰，你可以移除它。你也可以用這個來停止由失敗的大宗導入或失敗的ALTER TABLE 導致的失控回滾。你可以殺掉mysqld 進程，然後設置innodb_force_recovery 為3 ，使得數據庫被掛起而不需要回滾，然後捨棄導致失控回滾的表。
