(一)基本定義規範
1. 表達是與否概念的字段，必須使用 is_xxx 的方式命名，數據類型是 unsigned tinyint（1 表示是，0 表示否）。
說明：任何字段如果爲非負數，必須是 unsigned。
正例：表達邏輯刪除的字段名 is_deleted，1 表示刪除，0 表示未刪除。
2. 【強制】表名、字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只出現數字。數據庫字段名的修改代價很大，因爲無法進行預發佈，所以字段名稱需要慎重
考慮。
說明：MySQL 在 Windows 下不區分大小寫，但在 Linux 下默認是區分大小寫。因此，數據庫名、表名、字段名，都不允許出現任何大寫字母，避免節外生枝。
正例：aliyun_admin，rdc_config，level3_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, create_time, update_time。
說明：其中 id 必爲主鍵，類型爲 bigint unsigned、單表時自增、步長爲 1。create_time, update_time的類型均爲 datetime 類型。
10.【推薦】表的命名最好是遵循“業務名稱_表的作用”。
正例：alipay_task / force_project / trade_config
11.【推薦】庫名與應用名稱儘量一致。
12.【推薦】如果修改字段含義或對字段表示的狀態追加時，需要及時更新字段註釋。
13.【推薦】字段允許適當冗餘，以提高查詢性能，但必須考慮數據一致。冗餘字段應遵循：
1） 不是頻繁修改的字段。
2） 不是 varchar 超長字段，更不能是 text 字段。
3） 不是唯一索引的字段。
正例：商品類目名稱使用頻率高，字段長度短，名稱基本一不變，可在相關聯的表中冗餘存儲類目名
稱，避免關聯查詢。
14.【推薦】單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。
說明：如果預計三年後的數據量根本達不到這個級別，請不要在創建表時就分庫分表。
15.【參考】合適的字符存儲長度，不但節約數據庫表空間、節約索引存儲，更重要的是提升檢索速度。
(二) 索引規約
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
(三)常見的慢sql特徵以及優化方案
大sql特徵
1 表數據量大（隨時間推移）
2 關聯表多（關聯表超過4個）
3 表設計沒做冗餘
4 早期趕進度，業務關聯增多，後期改造成本高
如何改進
一、表字段冗餘設計
二、利用redis做二級緩存查詢
redis設置過期時間
redis獲取數據
三、合理創建表字段索引
四、利用搜索引擎：elasticsearch、mongodb
五、最後一些其他sql調優
1 頁面搜索嚴禁左模糊或者全模糊，如果需要請走搜索引擎來解決。
2 建組合索引的時候，區分度最高的在最左邊
3 不要使用count(列名)或count(常量)來替代count(*)
4 不要使用select * ，防止全表掃描
5 order by / group by 字段包括在索引當中減少排序，效率會更高。
6 大查詢分頁，不要一次返回太多數據
7 不做join，改爲在數據庫中做冗餘
8 儘量不在事務內做讀操作或者其他遠程訪問操作，事務裏面只做寫，儘量保障事務短
9 如果慢sql是因爲業務設計原因，考慮是否通過業務改造避免，比如原來要查30天的數據，現在查7天也能滿足需求
10 將數據庫的查詢轉成更高效的K-V或者內存緩存起來，有模糊查詢的，走搜索引擎
11 進行sql語句：看下錶是否where、order的字段未加索引或者join出來太多行
12 進行分庫分表，將大表拆小
阿里開發手冊 詳情請點擊
https://github.com/alibaba/p3c