1，單庫表別太多，通常保持在200如下爲宜mysql
2，儘可能避免SQL中出現運算，例如select a+6 from t，讓DB功能單一化redis
3，表設計儘可能小而精，能用5個字段就不要用6個（不絕對，取決於業務，該冗餘時堅定不要手軟）sql
4，SQL事務不能設計太大，好比一次性提交10W條insert，固然這個不只僅是性能問題了，可能直接內存溢出了緩存
通常來講insert事務的話，5K-1W來作批處理就能夠了（字段不能太大）併發
5，設計表的時候儘可能用」小數據類型」，好比儘可能避免text，blob等這些你們夥，優先使用ENUM和SET（小而美，範圍有限，百益無一害）nosql
6，設計表字段能用數字類型就千萬別用字符類型，好比存IP地址，用int，別用varchar（博客有參考）memcached
7，儘可能避免null字段，定義時儘可能使用 not null。緣由是容許null時不方便查詢優化，複合索引也會失效，並且若是列有索引時會額外佔用空間： a int(10) NOT NULL DEFAULT 0性能
8，圖片等你們夥不要存DB。大數據
A，大SQL儘可能拆分，多核CPU每一個CPU只能執行一個SQL，因此併發時，一堆小的可能效率更高一些，而且容易命中緩存，並且不容易長時間鎖表（不管什麼鎖都是時間越短越好），固然這個要結合實際狀況分析了，一大堆小的萬一增長IO負擔呢。優化
B，事務儘量的小，代碼別偷懶，全加到一個transaction中，道理很少說了
C，存儲過程，觸發器之類的能避就全避免了吧，維護不方便，人員變更時，不少時候就忘了，時間一長全是定時炸彈
D，禁止select *，不用問爲啥了，禁止就是禁止！須要啥就取啥是王道
E，update時，where語句儘可能要走索引，否則會全表掃描，通常狀況下，1G的數據至少10S（想一想這但是update啊，鎖住10S意味着啥）
F，or儘可能不用，改成in()，固然in的範圍太多也不行，儘可能別超100
G，仍是or，若是：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
H，避免 「% 前綴」模糊查詢 。由於會致使索引失效，大數據量下是災難
I，分頁時：Select a from A limit 10000,10; 這種大偏移量下效率很是低。能夠考慮以下幾個方案：
select a from A WHERE id>=xxxx limit 11;(將上一頁的最大值經過where id> 進行預處理，而後分頁)
select a from A WHERE id >= ( select a from A limit 10000,1 ) limit 10;
select a from A inner join (select a from A limit 10000,10) using (id) ;
J，避免使用count(*)，不知道爲何mysql優化這麼個東西有那麼難麼，可是實際上大數量下這個東西真心慢，1000W以上至少幾秒，做爲替代方案，考慮使用nosql例如redis，memcached存下來，可是要定時校對。還有一個辦法，直接作一個表存下來，每次增長或者減小都在這個表作update增減
K，UNION ALL 而非 UNION ，看須要啦，通常不用去重的業務的話去重壓力不小，能省則省
L，儘可能不用 INSERT SELECT，數據量大有延遲，同步完了可能有錯誤