點評阿里JAVA手冊之MySQL數據庫 （建表規約、索引規約、SQL語句、ORM映射）

 下載原版阿里JAVA開發手冊   【阿里巴巴Java開發手冊v1.2.0】

  本文主要是對照阿里開發手冊，註釋本身在工做中運用狀況。

  本文內容：MySQL數據庫 （建表規約、索引規約、SQL語句、ORM映射）

  本文難度係數爲三星（★★★） 本文爲第四篇

   第一篇 點評阿里JAVA手冊之編程規約（命名風格、常量定義、代碼風格、控制語句、註釋規約）

   第二篇 點評阿里JAVA手冊之編程規約（OOP 規約 、集合處理 、併發處理 、其餘）

   第三篇 點評阿里JAVA手冊之異常日誌（異常處理 日誌規約 ）

   第四篇 點評阿里JAVA手冊之MySQL數據庫 （建表規約、索引規約、SQL語句、ORM映射）

碼出高效、碼出質量。

代碼的字裏行間流淌的是軟件生命中的血液，質量的提高是儘量少踩坑，杜絕踩重複的坑，切實提高質量意識。另外，現代軟件架構都須要協同開發完成，高效協做即下降協同成本，提高溝通效率，所謂無規矩不成方圓，無規範不能協做。衆所周知，制訂交通法規表面上是要限制行車權，其實是保障公衆的人身安全。試想若是沒有限速，沒有紅綠燈，誰還敢上路行駛。對軟件來講，適當的規範和標準毫不是消滅代碼內容的創造性、優雅性，而是限制過分個性化，以一種廣泛承認的統一方式一塊兒作事，提高協做效率。

MySQL數據庫

(一) 建表規約

1. 【強制】表達是與否概念的字段，必須使用is_xxx的方式命名，數據類型是unsigned tinyint（ 1表示是，0表示否）。 說明：任何字段若是爲非負數，必須是unsigned。

    正例：表達邏輯刪除的字段名is_deleted，1表示刪除，0表示未刪除。

   【點評】規則存疑，更願意用相似deletedflag這樣的字段，便於擴展數據類型用【unsigned tinyint】，遵循

2. 【強制】表名、字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只出現數字。數據庫字段名的修改代價很大，由於沒法進行預發佈，因此字段名稱須要慎重考慮。

   正例：getter_admin，task_config，level3_name

   反例：GetterAdmin，taskConfig，level_3_name

  【點評】規則好，嚴格遵循

3.【強制】表名不使用複數名詞。

說明：表名應該僅僅表示表裏面的實體內容，不該該表示實體數量，對應於DO類名也是單數形式，符合表達習慣。

  【點評】規則好，嚴格遵循

4.【強制】禁用保留字，如desc、range、match、delayed等，請參考MySQL官方保留字。

 【點評】規則好，嚴格遵循

5. 【強制】主鍵索引名爲pk_字段名；惟一索引名爲uk_字段名；普通索引名則爲idx_字段名。 說明：pk_ 即primary key；uk_ 即 unique key；idx_ 即index的簡稱。

  【點評】規則好，嚴格遵循

6. 【強制】小數類型爲decimal，禁止使用float和double。 說明：float和double在存儲的時候，存在精度損失的問題，極可能在值的比較時，獲得不正確的結果。若是存儲的數據範圍超過decimal的範圍，建議將數據拆成整數和小數分開存儲。

 【點評】規則好，嚴格遵循

7. 【強制】若是存儲的字符串長度幾乎相等，使用char定長字符串類型。

 【點評】規則好，嚴格遵循

8. 【強制】varchar是可變長字符串，不預先分配存儲空間，長度不要超過5000，

     若是存儲長度大於5000，定義字段類型爲text，獨立出來一張表，用主鍵來對應，避免影響其它字段索引效率。

    【點評】規則好，嚴格遵循

9. 【強制】表必備三字段：id, gmt_create, gmt_modified。

     說明：其中id必爲主鍵，類型爲unsigned bigint、單表時自增、步長爲1。gmt_create, gmt_modified的類型均爲date_time類型。

   【點評】規則好，嚴格遵循 ，更喜歡用create_time和modify_time

10.【推薦】表的命名最好是加上「業務名稱_表的做用」。

     正例：tiger_task / tiger_reader / mpp_config

   【點評】規則好，嚴格遵循

11.【推薦】庫名與應用名稱儘可能一致。

  【點評】規則好，嚴格遵循

12.【推薦】若是修改字段含義或對字段表示的狀態追加時,須要及時更新字段註釋。

  【點評】規則好，嚴格遵循

13.【推薦】字段容許適當冗餘，以提升查詢性能，但必須考慮數據一致。冗餘字段應遵循：

   1）不是頻繁修改的字段。

   2）不是varchar超長字段，更不能是text字段。

   正例：商品類目名稱使用頻率高，字段長度短，名稱基本一成不變，可在相關聯的表中冗餘存儲類目名稱，避免關聯查詢。

   【點評】規則好，嚴格遵循

14.【推薦】單錶行數超過500萬行或者單表容量超過2GB，才推薦進行分庫分表。

   說明：若是預計三年後的數據量根本達不到這個級別，請不要在建立表時就分庫分表。

   【點評】規則好，嚴格遵循

15.【參考】合適的字符存儲長度，不但節約數據庫表空間、節約索引存儲，更重要的是提高檢索速度。

   正例：以下表，其中無符號值能夠避免誤存負數，且擴大了表示範圍。

  

對象	年齡區間	類型	表示範圍
人	150歲以內	unsigned tinyint	無符號值：0到255
龜	數百歲	unsigned smallint	無符號值：0到65535
恐龍化石	數千萬年	unsigned int	無符號值：0到約42.9億
太陽	約50億年	unsigned bigint	無符號值：0到約10的19次方

 

【點評】規則好，嚴格遵循

(二) 索引規約

  1.【強制】業務上具備惟一特性的字段，即便是多個字段的組合，也必須建成惟一索引。

   說明:不要覺得惟一索引影響了insert速度，這個速度損耗能夠忽略，但提升查找速度是明顯的；

   另外，即便在應用層作了很是完善的校驗控制，只要沒有惟一索引，根據墨菲定律，必然有髒數據產生。

  【點評】規則好，嚴格遵循

 2. 【強制】 超過三個表禁止join。須要join的字段，數據類型必須絕對一致；多表關聯查詢時，保證被關聯的字段須要有索引。

   說明：即便雙表join也要注意表索引、SQL性能。

  【點評】規則好，嚴格遵循

 3. 【強制】在varchar字段上創建索引時，必須指定索引長度，不必對全字段創建索引，根據實際文本區分度決定索引長度便可。

說明：索引的長度與區分度是一對矛盾體，通常對字符串類型數據，長度爲20的索引，區分度會高達90%以上，

   可使用count(distinct left(列名, 索引長度))/count(*)的區分度來肯定。

   【點評】規則好，嚴格遵循

4. 【強制】頁面搜索嚴禁左模糊或者全模糊，若是須要請走搜索引擎來解決。

   說明：索引文件具備B-Tree的最左前綴匹配特性，若是左邊的值未肯定，那麼沒法使用此索引。

   【點評】規則好，嚴格遵循

5. 【推薦】若是有order by的場景，請注意利用索引的有序性。

  order by 最後的字段是組合索引的一部分，而且放在索引組合順序的最後，避免出現file_sort的狀況，影響查詢性能。

  正例：where a=? and b=? order by c; 索引：a_b_c

  反例：索引中有範圍查找，那麼索引有序性沒法利用，如：WHERE a>10 ORDER BY b; 索引a_b沒法排序。

   【點評】規則好，嚴格遵循

6. 【推薦】利用覆蓋索引來進行查詢操做，避免回表。

 說明：若是一本書須要知道第11章是什麼標題，會翻開第11章對應的那一頁嗎？目錄瀏覽一下就好，這個目錄就是起到覆蓋索引的做用。

   正例：可以創建索引的種類：主鍵索引、惟一索引、普通索引，而覆蓋索引是一種查詢的一種效果，用explain的結果，extra列會出現：using index。

   【點評】規則好，嚴格遵循

         參考：http://www.cnblogs.com/zl0372/articles/mysql_32.html

               話說有這麼一個表：

     

                   複製代碼

                   CREATE TABLE `user_group` (

                     `id` int(11) NOT NULL auto_increment,

                     `uid` int(11) NOT NULL,

                     `group_id` int(11) NOT NULL,

                     PRIMARY KEY  (`id`),

                     KEY `uid` (`uid`),

                     KEY `group_id` (`group_id`),

                   ) ENGINE=InnoDB AUTO_INCREMENT=750366 DEFAULT CHARSET=utf8

 

                   複製代碼

                   看AUTO_INCREMENT就知道數據並很少，75萬條。而後是一條簡單的查詢：

                   SELECT SQL_NO_CACHE uid FROM user_group WHERE group_id = 245;

                   很簡單對不對?怪異的地方在於：

                   若是換成MyISAM作存儲引擎的時候，查詢耗時只須要0.01s，用InnoDB卻會是0.15s左右

若是隻是就這麼點差距其實不是什麼大不了的事，可是真實的業務需求比這個複雜，形成的差距也很大：MyISAM只須要0.12s，InnoDB則須要2.2s.，最終定位到問題癥結是在這條SQL。

         　Explain的結果是：

                   +----+-------------+------------+------+---------------+----------+---------+-------+------+-------+

                   | id | select_type | table      | type | possible_keys | key      | key_len | ref   | rows | Extra |

                   +----+-------------+------------+------+---------------+----------+---------+-------+------+-------+

                   |  1 | SIMPLE      | user_group | ref  | group_id      | group_id | 4       | const | 5544 |       |

                   +----+-------------+------------+------+---------------+----------+---------+-------+------+-------+

 

                     看起來已經用上索引了，而這條SQL語句已經簡單到讓我沒法再優化了。最後請前同事Gaston診斷了一下，他認爲：數據分佈上，group_id相同的比較多，uid散列的比較均勻，加索引的效果通常，可是仍是建議我試着加了一個多列索引：

                     ALTER TABLE user_group ADD INDEX group_id_uid (group_id, uid);

                     而後，難以想象的事情發生了……這句SQL查詢的性能發生了巨大的提高，竟然已經能夠跑到0.00s左右了。通過優化的SQL再結合真實的業務需求，也從以前2.2s降低到0.05s。

                   再Explain一次：

                   +----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+

                   | id | select_type | table      | type | possible_keys         | key          | key_len | ref   | rows | Extra       |

                   +----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+

                   |  1 | SIMPLE      | user_group | ref  | group_id,group_id_uid | group_id_uid | 4       | const | 5378 | Using index |

                   +----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+

原來是這種叫覆蓋索引(covering index)，MySQL只須要經過索引就能夠返回查詢所須要的數據，而沒必要在查到索引以後再去查詢數據，因此那是至關的快!!可是同時也要求所查詢的字段必須被索引所覆蓋到，在Explain的時候，輸出的Extra信息中若是有「Using Index」，就表示這條查詢使用了覆蓋索引。

不過，還有一個沒法解釋的問題就是，不用覆蓋索引的狀況下，爲何用MyISAM就快那麼多，而InnoDB就慢這麼多呢?

7. 【推薦】利用延遲關聯或者子查詢優化超多分頁場景。

    說明：MySQL並非跳過offset行，而是取offset+N行，而後返回放棄前offset行，返回N行，那當offset特別大的時候，效率就很是的低下，

     要麼控制返回的總頁數，要麼對超過特定閾值的頁數進行SQL改寫。

    正例：先快速定位須要獲取的id段，而後再關聯： SELECT a.* FROM 表1 a, (select id from 表1 where 條件 LIMIT 100000,20 ) b where a.id=b.id

   【點評】規則好，嚴格遵循

8. 【推薦】 SQL性能優化的目標：至少要達到 range 級別，要求是ref級別，若是能夠是consts最好。

   說明：1）consts 單表中最多隻有一個匹配行（主鍵或者惟一索引），在優化階段便可讀取到數據。

           2)  ref 指的是使用普通的索引（normal index）。

           3）range 對索引進行範圍檢索。

    反例：explain表的結果，type=index，索引物理文件全掃描，速度很是慢，這個index級別比較range還低，與全表掃描是小巫見大巫。

   【點評】規則好，嚴格遵循

9. 【推薦】建組合索引的時候，區分度最高的在最左邊。

    正例：若是where a=? and b=? ，a列的幾乎接近於惟一值，那麼只須要單建idx_a索引便可。

   說明：存在非等號和等號混合判斷條件時，在建索引時，請把等號條件的列前置。

   如：where a>? and b=? 那麼即便a的區分度更高，也必須把b放在索引的最前列。

   【點評】規則好，嚴格遵循

10. 【推薦】防止因字段類型不一樣形成的隱式轉換，致使索引失效。

    【點評】規則好，嚴格遵循

11. 【參考】建立索引時避免有以下極端誤解：

    1）寧濫勿缺。誤認爲一個查詢就須要建一個索引。

    2）寧缺勿濫。誤認爲索引會消耗空間、嚴重拖慢更新和新增速度。

    3）抵制唯一索引。誤認爲業務的唯一性一概須要在應用層經過「先查後插」方式解決。

   【點評】規則好，嚴格遵循

(三) SQL語句

1. 【強制】不要使用count(列名)或count(常量)來替代count(*)，count(*)是SQL92定義的標準統計行數的語法，跟數據庫無關，跟NULL和非NULL無關。

說明：count(*)會統計值爲NULL的行，而count(列名)不會統計此列爲NULL值的行。

   【點評】規則好，嚴格遵循       

2. 【強制】count(distinct col) 計算該列除NULL以外的不重複行數，

  注意 count(distinct col1, col2) 若是其中一列全爲NULL，那麼即便另外一列有不一樣的值，也返回爲0。

   【點評】規則好，嚴格遵循

3.【強制】當某一列的值全是NULL時，count(col)的返回結果爲0，但sum(col)的返回結果爲NULL，所以使用sum()時需注意NPE問題。

正例：可使用以下方式來避免sum的NPE問題：SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;

   【點評】規則好，嚴格遵循

4. 【強制】使用ISNULL()來判斷是否爲NULL值。注意：NULL與任何值的直接比較都爲NULL。

    說明： 1） NULL<>NULL的返回結果是NULL，而不是false。

             2） NULL=NULL的返回結果是NULL，而不是true。

             3） NULL<>1的返回結果是NULL，而不是true。

   【點評】規則好，嚴格遵循

5. 【強制】 在代碼中寫分頁查詢邏輯時，若count爲0應直接返回，避免執行後面的分頁語句。

   【點評】規則好，嚴格遵循

6. 【強制】不得使用外鍵與級聯，一切外鍵概念必須在應用層解決。

    說明：（概念解釋）學生表中的student_id是主鍵，那麼成績表中的student_id則爲外鍵。

   若是更新學生表中的student_id，同時觸發成績表中的student_id更新，則爲級聯更新。

   外鍵與級聯更新適用於單機低併發，不適合分佈式、高併發集羣；

   級聯更新是強阻塞，存在數據庫更新風暴的風險；外鍵影響數據庫的插入速度。

   【點評】規則好，嚴格遵循

7. 【強制】禁止使用存儲過程，存儲過程難以調試和擴展，更沒有移植性。

   【點評】規則好，嚴格遵循

8. 【強制】數據訂正時，刪除和修改記錄時，要先select，避免出現誤刪除，確認無誤才能執行更新語句。

   【點評】規則好，嚴格遵循

9. 【推薦】in操做能避免則避免，若實在避免不了，須要仔細評估in後邊的集合元素數量，控制在1000個以內。

   【點評】規則好，嚴格遵循

10. 【參考】若是有全球化須要，全部的字符存儲與表示，均以utf-8編碼，注意字符統計函數的區別。

說明： SELECT LENGTH("輕鬆工做")； 返回爲12;

 SELECT CHARACTER_LENGTH("輕鬆工做")； 返回爲4

   若是要使用表情，那麼使用utfmb4來進行存儲，注意它與utf-8編碼的區別。

  【點評】規則好，嚴格遵循

11. 【參考】 TRUNCATE TABLE 比 DELETE 速度快，且使用的系統和事務日誌資源少，但TRUNCATE無事務且不觸發trigger，有可能形成事故，故不建議在開發代碼中使用此語句。

  說明：TRUNCATE TABLE 在功能上與不帶 WHERE 子句的 DELETE 語句相同。

   【點評】規則好，嚴格遵循

(四) ORM映射

1. 【強制】在表查詢中，一概不要使用 * 做爲查詢的字段列表，須要哪些字段必須明確寫明。

    說明：1）增長查詢分析器解析成本。

            2）增減字段容易與resultMap配置不一致。

   【點評】規則好，嚴格遵循

2. 【強制】POJO類的布爾屬性不能加is，而數據庫字段必須加is_，要求在resultMap中進行字段與屬性之間的映射。

    說明：參見定義POJO類以及數據庫字段定義規定，在<resultMap>中增長映射，是必須的。

         在MyBatis Generator生成的代碼中，須要進行對應的修改。

   【點評】規則存疑，用flag結尾字段

3. 【強制】不要用resultClass當返回參數，即便全部類屬性名與數據庫字段一一對應，也須要定義；

    反過來，每個表也必然有一個與之對應。 說明：配置映射關係，使字段與DO類解耦，方便維護。

    【點評】規則好，嚴格遵循

4. 【強制】sql.xml配置參數使用：#{}，#param# 不要使用${} 此種方式容易出現SQL注入。

    【點評】規則好，嚴格遵循

5. 【強制】iBATIS自帶的queryForList(String statementName,int start,int size)不推薦使用。

     說明：其實現方式是在數據庫取到statementName對應的SQL語句的全部記錄，再經過subList取start,size的子集合。

     正例：Map<String, Object> map = new HashMap<String, Object>();

           map.put("start", start);

           map.put("size", size);

   【點評】規則好，嚴格遵循  

6. 【強制】不容許直接拿HashMap與Hashtable做爲查詢結果集的輸出。

    說明：resultClass=」Hashtable」，會置入字段名和屬性值，可是值的類型不可控。

   【點評】規則好，嚴格遵循  

7. 【強制】更新數據表記錄時，必須同時更新記錄對應的gmt_modified字段值爲當前時間。

   【點評】規則好，嚴格遵循  

8. 【推薦】不要寫一個大而全的數據更新接口，傳入爲POJO類，無論是否是本身的目標更新字段，都進行update table set c1=value1,c2=value2,c3=value3;

    這是不對的。執行SQL時，不要更新無改動的字段，

         一是易出錯；

         二是效率低；

         三是增長binlog存儲。

         【點評】規則好，嚴格遵循

9. 【參考】@Transactional事務不要濫用。

    事務會影響數據庫的QPS，

         另外使用事務的地方須要考慮各方面的回滾方案，包括緩存回滾、搜索引擎回滾、消息補償、統計修正等。

         【點評】規則好，嚴格遵循

10.【參考】<isEqual>中的compareValue是與屬性值對比的常量，通常是數字，表示相等時帶上此條件；

         <isNotEmpty>表示不爲空且不爲null時執行；<isNotNull>表示不爲null值時執行。

     【點評】規則好，嚴格遵循