1、基本規則

    1.1 、儘量不在資料庫做運算      運算儘可能移到程式端CPU。

    1.2、 控制單表資料量

     1.2.1、一年內的單表資料量預估       >純INT不超過1000W       >含CHAR不超過500W

     1.2.2、合理分表不超載       > 取模                 例如：id%n=0 —> tabel0;                            id%n=1 —> tabel1;                            id%n=2 —> tabel2;                                           …       > 時間                  例如可以根據月份、季度、年進行分表       > 雜湊                  例如一個電商網站，需要記錄使用者的所有購買記錄，如果將所有的記錄放到                  一張userBuy表中，勢必會非常巨大，所以我們可以通過對userid進行分表處                  理，將不同的使用者購買記錄放到不同的分表中，比如對userid做crc32的hash                  計算，然後用得到的雜湊值進行取餘，取餘的餘數就是你的分表數，餘數則                  是該userid需要記錄進入的表。       > 區域                  例如主鍵id範圍進行分表

      > 引擎.                  可以使用Mysql的MyISAM儲存引擎，因為其支援MERAGE型別，結合                  UNION來實現資料表的分割和資料同步。這種方式的優點就是可以保留表                  的外來鍵、事務以及其它屬性，但是缺點就是查詢效能比較低，同步也不夠                  靈活，所以大多不推薦這種方式實現分表。

     1.3、遵循三大正規化

      > 第一正規化（1NF）                 1NF是指資料庫中表的每一列都是不可分割的基本資料項，同一列的資料不                  能有多個值。如果出現重複，就可能需要定義一個新的實體（即：生成一                  個新的表）來描述關係。                  例如：公司中某個人員隸屬於多個部門，那麼在人員中，這個人部門欄位                  可以儲存多個值，但是這樣違反了1NF。                  解決辦法：此時可以生成一個新表，表示人員與部門的關係。

      > 第二正規化（2NF）                  2NF是在1NF的基礎上建立的，所以滿足2NF的必須滿足1NF；                  2NF要求資料庫中表的每個例項或行必須能唯一的區分。為實現區分通                             常需要為表加上一個列（主鍵）或多列（聯合主鍵）；                  2NF要求實體的屬性完全依賴於主鍵。如果存在依賴主鍵一部分的屬性                  那麼這個屬性和主鍵應該分離出來形成一個新的實體，新實體於原實體之間                  是一對多的關係。簡而言之，就是2NF非主屬性不能部分依賴於主鍵。

      > 第三正規化（3NF）                  3NF依賴於2NF；                  3NF要求一個數據庫表中不包含在其他表中已經存在的非主鍵的欄位；                  3NF表屬性不能依賴其他表中非主鍵的屬性；

     1.4、拒絕3B                      >大SQL（Big SQL）                      >大事務（Big Transaction）                      >大批量（Big Batch）

2、欄位規則

                     >將字串轉化為數字：查詢快、佔用空間小，比如無符號INT儲存IP。                      >優先使用Enum或SET:可能值已知且有限的字串型別。                      >避免使用NULL欄位：很難進行查詢優化、NULL列加索引，需要額外的                         空間、含NULL複合索引無效。                      >少用並拆分TEXT/BLOB                         Text型別處理效能遠低於VARCHAR(強制生成臨時表、浪費更多空間)                      >不在資料庫中存圖片

3、索引規則

                     >謹慎合理新增索引                         改善查詢                         減慢更新                         能不加索引則不加索引                      >大量重複值索引無效                         例如：性別列                      >不在索引列做數學或函式運算                         無法使用索引                         導致全表掃描                      >儘量不用外來鍵                         可到達其它表意味著“鎖”                         高併發容易死鎖

4、SQL優化

                     4.1、OR                         · 同一欄位將OR改寫為IN                         · 不同欄位將OR改寫為UNION                            舉例：Select * from opp where phone=‘010-88886666’ or cellPhone=                                     ‘13800138000’;                                       優化：                                        Select * from opp where phone=‘010-88886666’                                        union                                        Select * from opp where cellPhone=‘13800138000’;

                     4.2、避免負向查詢和%字首查詢                               >NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等                               >%字首：使用不了索引、導致全表掃描。

      國慶就要放假了，提前一天回家，啊啊啊啊啊啊啊，沒心情寫了，暫時就這些吧先，祝萬千猿友假期愉快！