快取講了乙個月《快取架構，一篇足夠》。今天，開始寫資料庫。
第一篇，說說mysql兩個最常用的儲存引擎，myisam和innodb。照自己的理解，把一些知識點總結出來，不只說知識點，多講「為什麼」。
一、關於count(*)
知識點：myisam會直接儲存總行數，innodb則不會，需要按行掃瞄。
潛台詞是，對於select count(*) from t; 如果資料量大，myisam會瞬間返回，而innodb則會一行行掃瞄。
實踐：資料量大的表，innodb不要輕易select count(*)，效能消耗極大。
常見坑：只有查詢全表的總行數，myisam才會直接返回結果，當加了where條件後，兩種儲存引擎的處理方式類似。
例如：
t_user(uid, uname, age, ***);
select count(*) where age<18 and ***='f';
查詢未成年少女個數，兩種儲存引擎的處理方式類似，都需要進行索引掃瞄。
啟示：不管哪種儲存引擎，都要建立好索引。
二、關於全文索引
知識點：myisam支援全文索引，innodb5.6之前不支援全文索引。
實踐：不管哪種儲存引擎，在資料量大併發量大的情況下，都不應該使用資料庫自帶的全文索引，會導致小量請求占用大量資料庫資源，而要使用《索引外接》的架構設計方法。
啟示：大資料量+高併發量的業務場景，全文索引，myisam也不是最優之選。
三、關於事務
知識點：myisam不支援事務，innodb支援事務。
實踐：事務是選擇innodb非常誘人的原因之一，它提供了commit，rollback，崩潰修復等能力。在系統異常崩潰時，myisam有一定機率造成檔案損壞，這是非常煩的。但是，事務也非常耗效能，會影響吞吐量，建議只對一致性要求較高的業務使用複雜事務。
畫外音：can't open file '***.myi'. 碰到過麼？
小技巧：myisam可以通過lock table表鎖，來實現類似於事務的東西，但對資料庫效能影響較大，強烈不推薦使用。
四、關於外來鍵
知識點：myisam不支援外來鍵，innodb支援外來鍵。
實踐：不管哪種儲存引擎，在資料量大併發量大的情況下，都不應該使用外來鍵，而建議由應用程式保證完整性。
五、關於行鎖與表鎖
知識點：myisam只支援表鎖，innodb可以支援行鎖。
分析：
myisam：執行讀寫sql語句時，會對錶加鎖，所以資料量大，併發量高時，效能會急劇下降。
innodb：細粒度行鎖，在資料量大，併發量高時，效能比較優異。
實踐：網上常常說，select+insert的業務用myisam，因為myisam在檔案尾部順序增加記錄速度極快。樓主的建議是，絕大部分業務是混合讀寫，只要資料量和併發量較大，一律使用innodb。
常見坑：
innodb的行鎖是實現在索引上的，而不是鎖在物理行記錄上。潛台詞是，如果訪問沒有命中索引，也無法使用行鎖，將要退化為表鎖。
畫外音：oracle的行鎖實現機制不同。
例如：
t_user(uid, uname, age, ***) innodb;
update t_user set age=10 where uid=1;
命中索引，行鎖。
update t_user set age=10 where uid != 1;
未命中索引，表鎖。
update t_user set age=10 where name='shenjian';
無索引，表鎖。
啟示：innodb務必建好索引，否則鎖粒度較大，會影響併發。
總結
在大資料量，高併發量的網際網路業務場景下，對於myisam和innodb
結論
在大資料量，高併發量的網際網路業務場景下，請使用innodb:
InnoDB，5項最佳實踐，知其所以然？
說說mysql兩個最常用的儲存引擎，myisam和innodb。照自己的理解，把一些知識點總結出來，不只說知識點，多講 為什麼 一 關於count 知識點 myisam會直接儲存總行數，innodb則不會，需要按行掃瞄。潛台詞是，對於select count from t 如果資料量大，myisam...
InnoDB，5項最佳實踐
mysql兩個最常用的儲存引擎，myisam和innodb 一 關於count 知識點 myisam會直接儲存總行數，innodb則不會，需要按行掃瞄。潛台詞是，對於select count from t 如果資料量大，myisam會瞬間返回，而innodb則會一行行掃瞄。例如 t user uid...
MySQL InnoDB，5項最佳實踐
一 關於count 知識點 myisam會直接儲存總行數，innodb則不會，需要按行掃瞄。潛台詞是，對於select count from t 如果資料量大，myisam會瞬間返回，而innodb則會一行行掃瞄。實踐 資料量大的表，innodb不要輕易select count 效能消耗極大。常見坑...