MyISAM的讀性能是比Innodb強
MyISAM的索引和數據是分開的，並且索引是有壓縮的
Innodb是索引和數據是緊密捆綁的，沒有使用壓縮從而會造成Innodb比MyISAM體積龐大不小
MyISAM不支持外鍵 Innodb支持
MyISAM不支持事務 Innodb支持
MyISAM只支持表所 Innodb支持行鎖
對數據信息的存儲方式不同，MyISAM創建一張表對應3個文件，Innodb則只有一個文件.frm，數據存儲在ibdata1
復制自己insert into tt select * from tt
--------------------------
恢復
不小心update一個表where寫的范圍不對，導致這個表沒法正常用了，這個時候MyISAM的優越性就體現出來了，隨便從當天拷貝的壓縮包取出對應表的文件，隨便放到一個數據庫目錄下，然後dump成sql再導回到主庫，並把對應的binlog補上。如果是Innodb，恐怕不可能有這麼快速度
--------------------------
鎖表
select count(*) 和order by 是最頻繁的，大概能占了整個sql總語句的60%以上的操作，而這種操作Innodb其實也是會鎖表的，很多人以為Innodb是行級鎖，那個只是where對它主鍵是有效，非主鍵的都會鎖全表的。
-------------------------
大小
保證數據庫單個實例盡量不要超過150G。
受文件系統操作限制，文件數過大需要更多文件句柄，且大目錄 操作造成復制、壓縮、備份效率低。
- 打開表占用數據庫資源（table_cache）
√ 建議一個庫不應超過300-400個表
√ 建議一般帶char字段的表不應超過500萬rows.基於數字的字段為主的表不要超過1000萬rows.
切分盡量多的小實例，一個機器跑7-8個實例，平常load avg不超過1-2，峰值不超過6-7為合理。
-------------------------
主從
通過分多個主庫,便於未來可擴展
通過使用replicate_do_db(table)來解決從庫追主庫延遲時間較長的問題由於mysql的從庫只能單進程追，而通過上述方式，就能形成多進程追不同庫來減少延遲，缺點是管理成本會很大。
---------------------------
多IDC
通過多IDC提升數據庫平台99.999%穩定性
---------------------------
分表
按時間(財經)
按ID號hash分(統一通行證)
按業務項目(通用投票)
merge引擎
提升代碼開發速度
1.
比如有些項目，需要定期存用戶離線消息，可以采取程序只訪問對應的merge表，然後merge表對應7個子表(比如周一到周日)。
2.
比如統計項目，可能分表策略是每個月一個表，然後要做如一季度，二季度的統計，為
了方便開發，可以采取程序只訪問對應merge表，然後自由結合1234，N表作為merge表的子表。
---------------------------
索引
正確使用索引，避免全表搜索 使用定長表,且定期做OPTIMIZE TABLE命令（注意這個命令會鎖表，請在數據庫訪問小的時候做） 在對大表進行添加索引，一定要選擇訪問小的時間段做，否則會導致嚴重問題。注:一般臨晨2-3點時候是大部分項目訪問的低谷。
索引優化，選擇實驗
穩妥地改進
將需要優化的相關表復制到測試環境
在測試環境啟動一個測試daemon，關閉query cache或是使用select SQL_NO_CACHE 方式。
未優化時測試若干次查詢時間，以及explain檢查掃描集。
選擇合適的索引試驗建立。可以通過use index(xx)來強制使用。檢查是否有效。
測試查詢時間變化，反復試驗得到最優結果
保持關注，根據情況隨時改變索引設置
采取從庫不同索引的模式來提升性能
比如有些項目，有很多不同的排序需求，需
要建立很多索引，但是如果都加必然導致性
能下降，所以采取不同功能使用對應索引的
從庫來解決。
-------------------------------------
排序
盡量使用帶主鍵的字段做order by 的排序 盡量不要多提供頁面的查找（最好只提供100頁內），避免機器爬蟲抓取數據，導致數據庫壓力負載過高。因為做order by field1 limit xxxxxx,20是非常消耗數據庫資源。 ------------------------------------- 批量 通過使用insert批量的方式來提升主庫的寫速度，通過批量values模式都能提升主庫寫性能。 -------------------------------------- key-value 通過簡單的key-value模式數據庫來處理簡單邏輯業務，如berkeley DB, LightCloud, Tokyo Tyrant ------------------------------------ NoSQL 通過Memcache來緩沖頻繁update的數據庫
