1.單庫表別太多，一般保持在200以下為宜.
2.盡量避免SQL中出現運算，例如select a+5 from A，讓DB功能單一化
3.表設計盡量小而精，能用5個字段就不要用6個（除非業務上使用增加冗余字段來提升性能）。
4.SQL事務不能設計太大，比如一次性提交10W條insert，當然這個不僅僅是性能問題了，可能直接內存溢出了。
一般來說insert事務的話，5K-1W來做批處理就可以了（字段不能太大）
5.設計表的時候盡量用”小數據類型”，比如盡量避免text，blob等這些大家伙，優先使用ENUM和SET（小而美，范圍有限，百益無一害）
6.設計表字段能用數字類型就千萬別用字符類型，比如存IP地址，用int，別用varchar（方法自己百度一下吧）。
7.盡量避免null字段，定義時盡量使用 not null。原因是允許null時不方便查詢優化，復合索引也會失效，而且如果列有索引時會額外占用空間： a int(10) NOT NULL DEFAULT 0
8.圖片等大家伙不要存DB，用FastDFS等中間件或者直接使用七牛等云存儲。
9.大SQL盡量拆分，多核CPU每個CPU只能執行一個SQL，所以并發時，一堆小的可能效率更高一些，并且容易命中緩存，而且不容易長時間鎖表（無論什么鎖都是時間越短越好），當然這個要結合實際情況分析了，一大堆小的萬一增加IO負擔呢。
10.事務盡可能的小，代碼別偷懶，全加到一個transaction中，盡量使用多個transaction。
11.存儲過程，觸發器之類的能避就全避免了吧，維護不方便，人員變動時，很多時候就忘了，時間一長全是定時炸彈。
12.禁止select *需要啥就取啥。
13.update時，where語句盡量要走索引，不然會全表掃描，一般情況下，1G的數據至少10S（想想這可是update啊，鎖住10S意味著啥）。
14.or盡量不用，改為in(),當然in的范圍太多也不行，盡量別超100。
15.還是or，如果：select a from A where b=1 or c=1這種where里面不同字段進行or，這種盡量改為union。
16.避免 “% 前綴”模糊查詢 。因為會導致索引失效，大數據量下是災難。
17.分頁時：Select a from A limit 10000,10;這種大偏移量下效率非常低。可以考慮如下幾個方案：
18.避免使用count(*)，不知道為什么mysql優化這么個東西有那么難么，但是實際上大數量下這個東西真心慢，1000W以上至少幾秒，作為替代方案，考慮使用nosql例如redis，memcached存下來，但是要定時校對。
還有一個辦法，直接做一個表存下來，每次增加或者減少都在這個表做update增減。
19.UNION ALL而非 UNION ，看需要啦，一般不用去重的業務的話去重壓力不小，能省則省。
20.盡量不用 INSERT SELECT，數據量大有延遲，同步完了可能有錯誤。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
