用於日誌表的Mysql存儲引擎

Question

用於mysql上的日誌表的最佳存儲引擎是什麼？

如果id字段（整數）是日期字段，消息級別的varchar和帶有消息的文本字段，表格將會有一對。

它會記錄所有事物，用戶操作，系統事件等。它預計將迅速增長。

它的記錄永遠不會被修改，很少被訪問。訪問時應按日期級別和ID排序。

一個有趣的選項是歸檔引擎。它符合所有標準，但有一大缺點，不僅無法刪除記錄，甚至無法清除表格。清除表的唯一方法是刪除它並重新創建它。

有什麼建議嗎？

Answer 1

那麼，根據你的問題時，InnoDB應該做的工作，因爲：

1. 它的可擴展性比的MyISAM好多了
2. 這是行鎖定，因此，如果您將會有超過寫選擇，它更適合。
3. 最後，既然你說他們很少被訪問，那麼就不需要MyISAM，因爲它在選擇查詢上更好。

Check this for more information

編輯

好了，你問其他引擎的評論。這是一個full list引擎。其中，正如你所說的歸檔有缺點，其他人不符合你的要求。下面是從MySQL網站報價：

InnoDB has been designed for maximum performance when processing large data volumes. 
Its CPU efficiency is probably not matched by any other disk-based relational database 
engine. 

所以基本上：

1. 如果你打算使用內存並不像你說的，你不會訪問數據了很多，你的表會增長太多。你將需要大量的RAM，當你重新啓動時，所有的數據都將丟失。
2. 如果您打算使用MyISAM，請不要使用MyISAM，因爲它是爲選擇查詢比插入和更新更頻繁的表而設計的。
3. 至於檔案，那是您的選擇。 Here是MyISAM和歸檔日誌表之間的比較。雖然我會堅持InnoDB。
4. 我甚至不會提到Merge，Blackhole，Example和其他引擎。 （我對CSV引擎沒有多少了解，但據我所知，這是一種不適合這種表的適當引擎。

說實話，我以前花了很多錢我研究了幾個小時，也許幾天瞭解一個問題，看看哪一種方式最合適，我會告訴你什麼，研究是好的，但是如果它妨礙了你的工作，那麼你應該停下來，喝一杯咖啡，然後馬上做出選擇，因此，只要嘗試一下最合適的一個，你會體驗到你會發現一個更好的方式，通過嘗試自己。我的意思是，我不認爲Facebook是爲這樣一個數量而設計的，但隨着它的增長，他們繼續相應地改變結構。這就是我相信雖然，可能不是現實:)無論如何，希望信息可以幫助你。

編輯2013

下面你會發現在內置的MySQL存儲引擎的簡要說明。

的MyISAM

這些表包括額外的優化，如高級高速緩存和索引機制，其提供對數據的快速訪問。使用表級鎖定，MyISAM存儲引擎提供併發操作。當讀取性能是一個問題時，一般來說，MyISAM是一種選擇。

存儲器

也稱爲堆表，存儲器表是理想的是很少改變的（如國家代碼，郵政編碼或其它查找表）頻繁使用的數據的快速retrievel。顧名思義，數據存儲在內存中，因此訪問速度比存儲在磁盤中的數據快得多。使用內存的一個重要限制是數據在MySQL會話期間有效。當它崩潰，或關閉數據丟失。

InnoDB的

一個情況下，你將不得不使用這個存儲引擎，當你需要使用外鍵或交易。 InnoDB比MyISAM更具有併發性，因爲它提供了行級鎖定。存儲引擎非常可靠。當你想要使用這個存儲的另一種情況是當你有更多的寫入而不是讀取時。當你經常向表中寫入數據時，嘗試使用這個存儲是比MyISAM更加併發的。

存檔

它被設計用於存儲壓縮格式的大量數據。這個存儲引擎的用例之一是存儲檔案或歷史數據或安全日誌。該表不使用索引，因此對於日常數據檢索和存儲而言，這不是一個好的選擇。它是行級鎖定，數據在需求時可以隨時解壓縮。而且，改變桌子是不可能的。

合併

合併用於駐留在同一臺機器上的「合併」分區表。當你將一個大表分成幾個較小的表並使用合併表同時訪問它們時，最大的好處就是它的速度。由於表中的數據較少，搜索和排序將更快。