參考鏈接：
http://www.nowamagic.net/academy/detail/32061020
http://www.cnblogs.com/hi-bazinga/archive/2012/06/05/2536806.html
http://www.cnblogs.com/ybwang/archive/2010/06/04/1751279.html
http://www.cnblogs.com/phoenixbai/p/mysql_best_practices.html
http://ariyue.iteye.com/blog/553541
基本知識
<p>
** 四大范式**
第一范式：每個屬性不可再分捌年，屬性原子性（高效查詢提高性能）
第二范式：非主屬性完全依賴于主屬性藐石，即消除非主屬性對主屬性的部分函數(shù)依賴關(guān)系（完全但不是直接箕戳，少冗余）
第三范式：確保每列都和主鍵列直接相關(guān)婆跑，而不是間接相關(guān)汰翠。非主屬性對主屬性不存在傳遞函數(shù)依賴關(guān)系（完全且直接）
BCNF：非主鍵字段必須依賴于整個主鍵字
事務(wù)隔離級別
讀未提交：實際很少用酌伊。
讀已提交：大多數(shù)數(shù)據(jù)庫的默認級別呻纹。解決臟讀問題吕座。
可重讀：mysql默認刨疼。解決了臟讀和不可重復(fù)讀問題泉唁。但有幻讀問題。
可串行化：最高的級別揩慕，強制事務(wù)排序使之不會相互沖突亭畜，解決幻讀問題。但會有性能問題迎卤。
臟讀（rollback）：A已更新一份數(shù)據(jù)拴鸵，B在此時讀取了同一份數(shù)據(jù)，由于某些原因，前一個RollBack了操作劲藐，則后一個事務(wù)所讀取的數(shù)據(jù)就會是不正確的八堡。
不可重復(fù)讀（update）：事務(wù)兩次查詢之中數(shù)據(jù)的內(nèi)容不一致 ，別的事務(wù)更新所致聘芜。
幻讀（insert）：事務(wù)兩次查詢之中數(shù)據(jù)的條數(shù)不一致 兄渺，別的事務(wù)新增所致。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
四個方面：數(shù)據(jù)庫設(shè)計汰现、SQL語句優(yōu)化挂谍、數(shù)據(jù)庫參數(shù)配置、恰當?shù)挠布Y源和操作系統(tǒng)服鹅。
一凳兵、數(shù)據(jù)庫設(shè)計
- 適度的反范式，根據(jù)業(yè)務(wù)場景做適度的冗余可以大大提高性能企软。
- 適當建立索引庐扫，以及復(fù)合索引。Cardinality越大仗哨，Selectivity越高的字段形庭，越是理想的建索引的對象
- 表的水平劃分和垂直劃分
- 主鍵不要設(shè)得太大 (InnoDB)，因為它是以B+樹形式存儲數(shù)據(jù)文件的厌漂。
- 文件萨醒，圖片等大文件用文件系統(tǒng)存儲，數(shù)據(jù)庫只存儲路徑苇倡。
- 避免頻繁讀寫富纸，盡量集中批量操作。
- 靜態(tài)表會更快（固定長度的表旨椒，無VARCHAR, TEXT, BLOB可變長度的string類型的字段的表為靜態(tài)表晓褪。否則，為動態(tài)表）综慎。
二涣仿、SQL語句優(yōu)化
慢日志
參數(shù)文件里配置：
slow_query_log=d:/slow.txt
long_query_time = 2
通過mysql自帶的工具（mysqldumpslow.pl）來分析慢日志。
2.Explain查看mysql執(zhí)行計劃
QUERY最佳實踐：
不要用 “SELECT *”,否則示惊，會讀多好港，傳輸多，且增加可避免的表掃描
不要 like ‘%item%’ but ‘item%’
前面有％米罚，這索引就沒辦法利用了钧汹。所以，若想用索引加快查詢速度录择，那前面別加%.Cardinaltiy (基數(shù)) & Selectivity (選擇比)
Cardinality: 不同值的個數(shù)拔莱。如表t中其有100條記錄类嗤， 字段owner也有100條值，但其中10個不相同的值辨宠。這10就是這字段的Cardinality.
Selectivity: 10/100 = 10%就是這字段的selectivity.
這概念主要用來判斷此字段是否適合建索引。Cardinality越大货裹，Selectivity越高的字段嗤形，越是理想的建索引的對象。有時數(shù)據(jù)庫會根據(jù)這個值來決定弧圆，是利用索引還是掃表赋兵。所以說，不是你建了索引搔预，人家就會用的霹期。而且，索引不可太多拯田，多了反而會拖慢更新速度历造。ORDER BY created DESC的優(yōu)化
時間排序是應(yīng)用中比較常見的需求。細想船庇，這時間不是自增長的嘛吭产？那跟ID自增長不是一回事兒嘛？ 所以說鸭轮，在ORDER BY 時臣淤，用自增長的主鍵ID，會比用created窃爷，省一個FILE SORT操作邑蒋。快很多的按厘。Count(1), count(), count(owner)的區(qū)別
count(1)等同于count()医吊，等同于count(任何一個NOT NULL的字段)
count(owner)：若owner是可NULL的，則數(shù)出來的數(shù)跟上面的三種情況會少的刻剥。少的正好是那些owner is null的個數(shù)遮咖。Don`t JOIN ON 不同數(shù)據(jù)類型
A表user_id作為B表的外鍵，這種很常見造虏。此時御吞，需注意user_id字段的類型，在兩張表里都要保持一致漓藕。這樣節(jié)省不必要的開支陶珠，比如，數(shù)據(jù)庫替你做類型轉(zhuǎn)換等享钞。不要用全文索引(full-text index)
當前只有MyISAM才支持全文索引揍诽。而且诀蓉，不太好用，可自定義性比較差暑脆，所以完全無視它即可渠啤。若真需要做全文索引，還是考慮用Lucene, Solr, ElasticSearch, Sphinx, Groonga, Xapian等吧添吗。個個都是行家里手沥曹，功能齊全，可定義性強碟联，隨你搞妓美。Limit n,m 慢，慎用
大部分人翻頁鲤孵，可能都是靠這個的壶栋。數(shù)據(jù)量大時，這顯然會很慢普监。網(wǎng)上有人推薦說贵试，第一次查出來后氮采，記住當前頁的最后一個ID壹无，然后，在查詢下一頁時崔赌，把這個ID做為限制條件加進去漆际，然后取limit pagesize淆珊。
諸如此類，若細想奸汇，應(yīng)該是能想出點兒可行之策的我覺的施符。其實，當數(shù)據(jù)量很大時擂找，你可以換個角度想戳吝，如繼續(xù)在limit n,m上做文章能還是直接換個查詢方式，如用搜索引擎等贯涎。
百萬級數(shù)據(jù)量時听哭，limit優(yōu)化
小小的索引+一點點的改動就使mysql 可以支持百萬甚至千萬級的高效分頁
- 建立復(fù)合索引
- 通用優(yōu)化索引，找出id塘雳，再拼成 ”292陆盘，2492，38败明，12000“這樣的字符串
- 再次用 where id in 語句查詢出結(jié)果
100萬的數(shù)據(jù)隘马，160萬數(shù)據(jù)，15G表妻顶，190M索引
如果對于有where 條件酸员，又想走索引用limit的蜒车，必須設(shè)計一個索引，將where 放第一位幔嗦，limit用到的主鍵放第2位酿愧，而且只能select 主鍵！
三邀泉、數(shù)據(jù)庫參數(shù)配置
nnodb_additional_mem_pool_size = 64M
innodb_buffer_pool_size = 5G
四寓娩、合理的硬件資源和操作系統(tǒng)
讀寫分離 binlog
主庫master用來寫入，slave1—slave3都用來做select呼渣，每個數(shù)據(jù)庫分擔的壓力小了很多。工具：mysql-proxy(官方)寞埠，amobe for mysql（新浪）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
導(dǎo)致引擎放棄使用索引而進行全表掃描常見情況：
- 在 where 子句中對字段進行 null 值判斷
- 在 where 子句中使用!=或<>操作符
- 在 where 子句中使用 or 來連接條件屁置，可以用 union all 來改寫。
- in 和 not in 也要慎用仁连，因為IN會使系統(tǒng)無法使用索引,而只能直接搜索表中的數(shù)據(jù),對于連續(xù)的數(shù)值蓝角，能用 between 就不要用 in .
- 在 where 子句中對字段進行表達式操作
- 在 where 子句中的“=”左邊進行函數(shù)、算術(shù)運算或其他表達式運算
- 能用DISTINCT的就不用GROUP BY
- 盡量不要用SELECT INTO語句饭冬。 SELECT INOT 語句會導(dǎo)致表鎖定使鹅，阻止其他用戶訪問該表。
- 避免在索引列上使用計算昌抠，not患朱，in和<>等操作
- 當只需要一行數(shù)據(jù)的時候使用limit 1
