什麼是表引擎
我們看到的表結構，它的本質是資料在硬碟中的儲存。根據不同的特性，資料的儲存方式不同。比如：對於每一條資料，在硬碟中它是怎麼儲存的，怎麼壓縮的，怎麼建立索引和優化的，它的讀取和寫入是怎麼實現的。這些完整的一條路徑，我們稱之為表引擎。
選擇的依據
選擇的依據，是我們的需求，我們的需求很大程度上決定我們的選擇。有的時候，我們的習慣決策著這個過程。這裡，我們關注一下方面：
併發性，同一時間支援的寫入和讀取特性；
安全性，物理儲存結構，異常發生時資料的是否可靠；
事務性，資料執行的顆粒，以及提供的定義原子操作的特性；
查詢優化，這裡我們指查詢快取和索引；
在開發上，我們主要關注：（1,3,4），在運維層面，我們關注（2）。
在表的選擇上，最常用的是如下：
myisam
innodb
memory（heap）
從案例開始
mysiam
在5.0的時代，這個表是使用得非常普遍的，我了解的discuz就是使用這種表。它的優勢：查詢速度，被很多人看重。我們看看它的一些特點：
理論上儲存無限制（與作業系統的檔案系統有關）
存在text/blob全文索引
索引快取
資料壓縮
低儲存空間和低記憶體占用
高速寫入
查詢快取
序列寫入時，全表鎖（讀和寫）
不支援事務
集群支援
b-tree索引
create table a_myisam (.....) engine = myisam;
以上特性，我們看到myisam主要是為查詢而設計的，也是最初大家做資料儲存時考慮的東西。
innodb 從5.1開始，innodb慢慢發展起來，並且成為重要資料的儲存引擎。它的特點如下：
有限制的儲存
索引快取
支援事務
查詢快取
寫入行鎖
b-tree索引
create table a_myisam (.....) engine = innodb;
innodb更加穩定和成熟，也為更多需求提供解決方案。
memory
查詢速度快
mysql重啟後丟失
b-tree和hash索引
僅僅是為了快，小量資料。
這意味著什麼？我們的寫入速度要夠快且寫入不影響讀取。或者，我們可以並行寫入。這種情況，如果我們選擇myisam，寫入量的增加會導致全表上鎖，以至於讀取時，要等待鎖的釋放；那麼，顯然，myisam會造成表效能瓶頸。這種情況，我們選擇innodb。理由如下：
innodb寫入時，鎖為行鎖；不影響其它寫入，影響少量讀（有可能大量）；
innodb的查詢效能理論上比myisam稍差，但是非常小，可忽略；
這個時候，選擇myisam，沒有什麼問題。（讀/寫比較高）
查詢是否前10個
增加積分
如何實現？
一般情況下我們會增加乙個欄位來做標記，這個字段假設為：lock，那麼更新的時候保證這個中間是沒有其它操作的。我們稱之為事務。
start
select ... from table where lock = 0 for update;
update table set lock = 1;
commit
呵呵，這個不用說了，使用innodb和memory都可以。一般我們使用記憶體儲存，會把它當做k-v來使用，根據設計的情況來選擇。（不過，業內很少時候，記憶體的儲存一般都會選擇memcache和redis）。
總結一下
如果讀/寫 比很大的話，假設這個尺度為10，那麼，就使用myisam（寫入併發小的情況）
如果需要事務的支援，使用innodb
如果需要對併發性（寫入）有要求的話，使用innodb
其它情況，可以根據實際場景選擇
選擇合適的資料庫
這部分在nosql精粹這本書的混合持久化到選擇合適的資料庫，即第13章到第15章描述的非常好。推薦大家閱讀下。使用鍵值對資料庫來儲存購物車和會話資料，使用文件資料庫來儲存已完成的訂單 使用庫存及產品 來儲存關係型資料庫，關係型資料庫在事務處理上面的優勢是其他資料庫不可比擬的 使用它圖資料庫來儲存客戶...
php 資料庫高階操作
資料庫高階操作 1 獲取報錯資訊mysql error mysql errno string mysql error resource link identifier 返回上乙個mysql函式的錯誤文字，如果沒有出錯則返回空字串 int mysql errno resource link ident...
React 高階之選擇合適的元件型別
最近專案基本都是用 react，今天總結分享 react component 常見的幾種形式，如果你在寫 react 時經常不知道怎麼拆分 這篇文章或許對你有所幫助。為了更充分理解 react，先搞懂平時寫的 jsx 是什麼。初學的時候有比較大困惑，這是一門新語言嗎？大部分人是匆匆掃過文件就開始開發...