4個大的方向：分庫 、 讀寫分離 、 設計好索引 、 優(yōu)化你的查詢Sql

13太保：

1，單庫表別太多，一般保持在200以下

2，盡量避免SQL中出現(xiàn)運算，例如select a*2 from A where 3*bb = ddd

3，表設計盡量小而精，能用5個字段就不要用6個（取決于業(yè)務，該冗余時堅決不要手軟）

4，SQL事務不能設計太大，比如一次性提交10W條insert，當然這個不僅僅是性能問題了，可能直接內(nèi)存溢出了

一般來說insert事務的話，500-1000來做批處理就可以了（字段不能太大）

5，設計表的時候盡量用"小數(shù)據(jù)類型"，比如盡量避免text，blob等這些大家伙

6，設計表字段能用數(shù)字類型就千萬別用字符類型，比如存IP地址，用int，別用varchar

7，盡量避免null字段，定義時盡量使用 not null.原因是允許null時不方便查詢優(yōu)化，復合索引也會失效，而且如果列有索引時會額外占用空間： a int(10) NOT NULL DEFAULT 0

8，圖片等大家伙不要存DB，用fastdfs等中間件或者直接使用七牛等云存儲都可以搞，也不貴

9, or盡量不用，改為in(),當然in的范圍太多也不行，盡量別超100

如果：select a from A where b=1 or c=1這種where里面不同字段進行or，這種盡量改為union。 select a from A where b=1 union select a from A where c=1

10, update時，where語句盡量要走索引，不然會全表掃描，一般情況下，1G的數(shù)據(jù)至少10秒（想想這可是update啊，鎖住10S意味著啥）

11, 大SQL盡量拆分，多核CPU每個CPU只能執(zhí)行一個SQL，所以并發(fā)時，一堆小的可能效率更高一些，并且容易命中緩存，而且不容易長時間鎖表（無論什么鎖都是時間越短越好），當然這個要結(jié)合實際情況分析了，一大堆小的萬一增加IO負擔呢。

12, 避免 “% 前綴”模糊查詢 。因為會導致索引失效，大數(shù)據(jù)量下是災難

13, 分頁時：Select a from A limit 10000,10; 這種大偏移量下效率非常低

可以考慮如下 select a from A WHERE id>=xxxx limit 11;