MySQL 數據庫

(一)建表規約
1. 【強制】表達是與否概念的字段，必須使用 is_xxx 的方式命名，數據類型是 unsigned tinyint
（1 表示是， 0 表示否）。
說明： 任何字段若是爲非負數，必須是 unsigned。
注意： POJO 類中的任何布爾類型的變量，都不要加 is 前綴，因此，須要在<resultMap>設置
從 is_xxx 到 Xxx 的映射關係。數據庫表示是與否的值，使用 tinyint 類型，堅持 is_xxx 的
命名方式是爲了明確其取值含義與取值範圍。
正例： 表達邏輯刪除的字段名 is_deleted， 1 表示刪除， 0 表示未刪除。
2. 【強制】表名、字段名必須使用小寫字母或數字， 禁止出現數字開頭，禁止兩個下劃線中間只
出現數字。數據庫字段名的修改代價很大，由於沒法進行預發佈，因此字段名稱須要慎重考慮。
說明： MySQL 在 Windows 下不區分大小寫，但在 Linux 下默認是區分大小寫。所以，數據庫名、
表名、字段名，都不容許出現任何大寫字母，避免節外生枝。
正例： aliyun_admin， rdc_config， level3_name
反例： AliyunAdmin， rdcConfig， 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，若是存儲長
度大於此值，定義字段類型爲 text，獨立出來一張表，用主鍵來對應，避免影響其它字段索
引效率。
9. 【強制】表必備三字段： id, gmt_create, gmt_modified。
說明： 其中 id 必爲主鍵，類型爲 bigint unsigned、單表時自增、步長爲 1。 gmt_create,
gmt_modified 的類型均爲 datetime 類型，前者如今時表示主動建立，後者過去分詞表示被
動更新。
阿里巴巴 Java 開發手冊
26/38
10.【推薦】表的命名最好是加上「業務名稱_表的做用」。
正例： alipay_task / force_project / trade_config
11.【推薦】庫名與應用名稱儘可能一致。
12.【推薦】若是修改字段含義或對字段表示的狀態追加時，須要及時更新字段註釋。
13.【推薦】字段容許適當冗餘，以提升查詢性能，但必須考慮數據一致。冗餘字段應遵循：
1） 不是頻繁修改的字段。
2） 不是 varchar 超長字段，更不能是 text 字段。
正例： 商品類目名稱使用頻率高，字段長度短，名稱基本一成不變，可在相關聯的表中冗餘存
儲類目名稱，避免關聯查詢。
14.【推薦】單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。
說明： 若是預計三年後的數據量根本達不到這個級別，請不要在建立表時就分庫分表。
15. 【參考】合適的字符存儲長度，不但節約數據庫表空間、節約索引存儲，更重要的是提高檢
索速度。
正例： 以下表，其中無符號值能夠避免誤存負數， 且擴大了表示範圍。

人	150 歲以內	tinyint unsigned	1	無符號值： 0 到 255
龜	數百歲	smallint unsigned	2	無符號值： 0 到 65535
恐龍化石	數千萬年	int unsigned	4	無符號值： 0 到約 42.9 億
太陽	約 50 億年	bigint unsigned	8	無符號值： 0 到約 10 的 19 次方

(二)索引規約
1. 【強制】業務上具備惟一特性的字段，即便是多個字段的組合，也必須建成惟一索引。
說明： 不要覺得惟一索引影響了 insert 速度，這個速度損耗能夠忽略，但提升查找速度是明
顯的； 另外，即便在應用層作了很是完善的校驗控制，只要沒有惟一索引，根據墨菲定律，必
然有髒數據產生。
2. 【強制】超過三個表禁止 join。須要 join 的字段，數據類型必須絕對一致； 多表關聯查詢時，
保證被關聯的字段須要有索引。
說明： 即便雙表 join 也要注意表索引、 SQL 性能。
3. 【強制】在 varchar 字段上創建索引時，必須指定索引長度，不必對全字段創建索引，根據
實際文本區分度決定索引長度便可。
阿里巴巴 Java 開發手冊
27/38
說明： 索引的長度與區分度是一對矛盾體，通常對字符串類型數據，長度爲 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。
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 c>? and
d=? 那麼即便 c 的區分度更高，也必須把 d 放在索引的最前列， 即索引 idx_d_c。
阿里巴巴 Java 開發手冊
28/38
10.【推薦】 防止因字段類型不一樣形成的隱式轉換， 致使索引失效。
11.【參考】建立索引時避免有以下極端誤解：
1） 寧濫勿缺。 認爲一個查詢就須要建一個索引。
2） 寧缺勿濫。 認爲索引會消耗空間、嚴重拖慢更新和新增速度。
3） 抵制唯一索引。 認爲業務的唯一性一概須要在應用層經過「先查後插」方式解決