MySQL开发规约
MySQL開發規約
- 一、基礎規約
- 二、建表規約
- 三、索引規約
- 四、SQL規約
- 五、行為規約
一、基礎規約
使用INNODB存儲引擎
表字符集使用UTF8
所有表和字段都需要添加注釋
單表數據量建議控制在5000W以內，存儲大小60G以內
不在數據庫中存儲圖片、文件等大數據
禁止在線上做數據庫壓力測試
禁止從測試、開發環境直連數據庫
二、建表規約
- 1.【強制】表中必須有主鍵，并且類型為int/bigint、單表自增、步長為1，如果是分片表，采用了全局id生成器，確保生成的值是整型、自增有序。
說明：- 1）MySQL使用binlog進行主從復制，當binlog為row模式時，數據是一條一條在從庫執行的，當沒有主鍵和其它唯一非空約束字段時會全表掃描（delete和update）。
- 2）innodb引擎是以主鍵為索引來組織數據的，主鍵不僅是B+樹主索引的鍵，它還會包含在其它索引項中，所以小巧為好。
- 3）B+樹索引是有序的，自增有序的主鍵在插入數據時可大量減少頁分裂帶來的數據移動，并減少數據碎片。
- 2.【強制】表名、字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只出現數字。數據庫字段名的修改代價很大，因為無法進行預發布，所以字段名稱需要慎重考慮。
正例：getter_admin，task_config，level3_name
反例：GetterAdmin，taskConfig，level_3_name - 3.【強制】禁用保留字，如desc、range、match、delayed、virtual等，請參考MySQL官方保留字。
- 4.【強制】主鍵索引名為pk_字段名；唯一索引名為uk_字段名；普通索引名則為idx_字段名。
說明：pk_ 即primary key；uk_ 即 unique key；idx_ 即index的簡稱。 - 5.【強制】小數類型為decimal，禁止使用float和double。
說明：float和double在存儲的時候，存在精度損失的問題，很可能在值的比較時，得到不正確的結果。如果存儲的數據范圍超過decimal的范圍，建議將數據拆成整數和小數分開存儲。 - 6.【強制】如果存儲的字符串長度幾乎相等，使用char定長字符串類型。
- 7.【強制】varchar是可變長字符串，不預先分配存儲空間，長度不要超過5000，如果存儲長度大于此值，定義字段類型為text，獨立出來一張表，用主鍵來對應，避免影響其它字段索引效率。
- 8.【推薦】表的命名最好是加上“業務名稱_表的作用”。
正例：tiger_task / tiger_reader / mpp_config - 9.【推薦】庫名與應用名稱盡量一致。
- 10.【推薦】如果修改字段含義或對字段表示的狀態追加時，需要及時更新字段注釋。
- 11.【推薦】字段允許適當冗余，以提高性能，但是必須考慮數據同步的情況。冗余字段應遵循：
- 1）不是頻繁修改的字段。
- 2）不是varchar超長字段，更不能是text字段。
正例：商品類目名稱使用頻率高，字段長度短，名稱基本一成不變，可在相關聯的表中冗余存儲類目名稱，避免關聯查詢。
- 13.【參考】合適的字符存儲長度，不但節約數據庫表空間、節約索引存儲，更重要的是提升檢索速度。
正例：如下表，其中無符號值可以避免誤存負數，且擴大了表示范圍。
| 人 | 150歲之內 | unsigned tinyint | 無符號值：0到255 |
| 龜 | 數百歲 | unsigned tinyint | 無符號值：0到65535 |
| 恐龍化石 | 數千萬年 | unsigned int | 無符號值：0到約42.9億 |
| 太陽 | 約50億年 | unsigned bigint | 無符號值：0到約10的19次方 |
- 14.【參考】表設計不要超過50個字段，字段太多考慮拆分成多個表。這個可以減少SQL復雜度，減少IO消耗。
三、索引規約
-
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。 -
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.【參考】創建索引時避免有如下極端誤解：
- 1）寧濫勿缺。誤認為一個查詢就需要建一個索引。
- 2）寧缺勿濫。誤認為索引會消耗空間、嚴重拖慢更新和新增速度。
- 3）抵制惟一索引。誤認為業務的惟一性一律需要在應用層通過“先查后插”方式解決。
四、SQL規約
- 1.【強制】不使用select *，也不要select出所有字段，只查詢出需要的字段
說明：
消耗CPU和IO、消耗網絡帶寬
無法使用覆蓋索引
減少表結構變更帶來的影響
因為大，select/join可能生成臨時表 - 2.【強制】避免數據類型隱式轉換、避免在where后面的關鍵列使用函數。會導致索引失效
- 3.【強制】不要使用count(列名)或count(常量)來替代count()，count()是SQL92定義的標準統計行數的語法，跟數據庫無關，跟NULL和非NULL無關。
說明：count(*)會統計值為NULL的行，而count(列名)不會統計此列為NULL值的行。 - 4.【強制】count(distinct col) 計算該列除NULL之外的不重復行數，注意 count(distinct col1, col2) 如果其中一列全為NULL，那么即使另一列有不同的值，也返回為0。
- 5.【強制】當某一列的值全是NULL時，count(col)的返回結果為0，但sum(col)的返回結果為NULL，因此使用sum()時需注意NPE問題。
正例：可以使用如下方式來避免sum的NPE問題：SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table; - 6.【強制】使用ISNULL()來判斷是否為NULL值。注意：NULL與任何值的直接比較都為NULL。
說明：- 1） NULL<>NULL的返回結果是NULL，而不是false。
- 2） NULL=NULL的返回結果是NULL，而不是true。
- 3） NULL<>1的返回結果是NULL，而不是true。
- 7.【強制】 在代碼中寫分頁查詢邏輯時，若count為0應直接返回，避免執行后面的分頁語句。
- 8.【強制】不得使用外鍵與級聯，一切外鍵概念必須在應用層解決。
說明：（概念解釋）學生表中的student_id是主鍵，那么成績表中的student_id則為外鍵。如果更新學生表中的student_id，同時觸發成績表中的student_id更新，則為級聯更新。外鍵與級聯更新適用于單機低并發，不適合分布式、高并發集群；級聯更新是強阻塞，存在數據庫更新風暴的風險；外鍵影響數據庫的插入速度。 - 9.【強制】禁止使用存儲過程，存儲過程難以調試和擴展，更沒有移植性。
- 10.【強制】數據訂正時，刪除和修改記錄時，要先select，避免出現誤刪除，確認無誤才能執行更新語句。
- 11.【推薦】減少數據庫的交互次數
INSERT … ON DUPLICATE KEY UPDATE
REPLACE INTO、INSERT IGNORE、INSERT INTO VALUES(),(),()
UPDATE …WHERE ID IN(10,20,50, …) - 12.【推薦】使用in代替or，in的值控制在1000個之內。
- 13.【參考】如果有全球化需要，所有的字符存儲與表示，均以utf-8編碼，那么字符計數方法
注意：
說明：
SELECT LENGTH(“輕松工作”)； 返回為12
SELECT CHARACTER_LENGTH(“輕松工作”)； 返回為4
如果要使用表情，那么使用utfmb4來進行存儲，注意它與utf-8編碼的區別。 - 14.【參考】 TRUNCATE TABLE 比 DELETE 速度快，且使用的系統和事務日志資源少，但TRUNCATE無事務且不觸發trigger，有可能造成事故，故不建議在開發代碼中使用此語句。
說明：TRUNCATE TABLE 在功能上與不帶 WHERE 子句的 DELETE 語句相同。
五、行為規約
批量導入、導出數據必須提前通知DBA協助觀察
禁止有super權限的應用程序賬號存在
產品出現非數據庫導致的故障時及時通知DBA協助排查
推廣活動或上線新功能必須提前通知DBA進行流量評估
數據庫數據丟失，及時聯系DBA進行恢復
對單表的多次alter操作必須合并為一次操作
不在MySQL數據庫中存放業務邏輯
重大項目的數據庫方案選型和設計必須提前通知DBA參與
對特別重要的庫表，提前與DBA溝通確定維護和備份優先級
不在業務高峰期批量更新、查詢數據庫
提交線上建表改表需求，必須詳細注明所有相關SQL語句
總結
- 上一篇： 电气常见问题解答1
- 下一篇： 光伏电站监控系统基本架构及系统配置