#### 1. 數據庫設計基本規范
* 領域驅動表內容劃分，一個領域內容的放在一個表內.
* 一套應用表或者一張表，最基本要滿足第三范式要求.
* 對于基礎服務的表，要滿足BC范式的要求.
#### 2. 表名規范
* 同一個應用(或領域)下的表，要有相同的前綴，如：tb_share, tb_position,tb_valuation
* 簡潔、見名知意， 如：csm代表渠道結算，全名channel settlement， 用全名會很長，csm簡寫會方便很多
* 專業，因為我們是做金融的很多詞匯都是有專業詞匯的，建議多用專業詞匯命名，推薦網站：MBA智庫百科
#### 3. 字段名規范
* 專業、簡潔 比如取現：withdraw，不用cash等，持倉是position，份額是share
* 同一個系統中各個表中同樣含義的字段，單詞要一致，如用戶ID，在很多表中都用user_id，就不要用member_id,一致性方便大家理解
#### 4. 字段數據類型規范
* 如果需要時分秒時間記錄，建議用datetime類型
* 如果需要的更多是日期的查詢，建議用int型，不用DATE, 如20160909等，性能更高，空間更小
* 如果需要比時分秒更精確的時間記錄，建議用long型，用應用生成時間戳，System.currentTimeMillis()進行存儲
* 字符串存儲能用varchar不要用text，varchar存儲，搜索性能都高于text，text查詢是會產生臨時磁盤文件，性能差
* 備注字段如果不是特別長，盡量用varchar不用text，在daoImpl層處理超出長度部分，進行截取存儲
* 數字類型選擇，放棄float和double，盡量用decimal
* 放棄用BLOB二進制數據類型，如果涉及大數據存儲，進行DB-索引-文件存儲系統模式來處理
* 整數類型的具體選擇，下面單獨講解
#### 5. 整數型字段選擇規范
| 類型 | 占用字節 | 范圍 |
| --- | --- | --- |
| tinyint | 1 | -128~127 |
| smallint | 2 | -32768~32767 |
| mediumint | 3 | -8388608~8388607） |
| int | 4 | -2147483648~2147483647 |
| bigint | 8 | +-9.22*10的18次方 |
**原則：**
* 不浪費空間, 能用小的數據類型干嘛占用那么多空間
* 能用int，不影響業務理解，不用char
* 方便以后擴容，支持以后擴容需求
* 注意int(1), int(10),沒有存儲空間上的差別，只是在補0查詢是，占位達到的位數，所以空間還是類型的選擇
例如：
direction表示收支方向， 就收，支，平，三個值，直到滄海桑田，海枯石爛也是三個值，所以一定用tinyint(1)，省空間，效率高;
#### 6. 金融金額字段默認規范
* 用decimal來存儲金額字段，不要用float和double，會出現數據精度丟失，不信可以自己試試
* decimal(M,N)，
* M和D的關系（存儲規則M>=D(M必須大于等于D)
* 整數位最大長度M-N位，小數位長度N位
* 占用字節數最大為M+2個字節數(保護-號和.的情況)
* 金融金額字段建議DECIMAL(16,2)的數據類型，占用空間18個字節，小數保留到分，整數14位，最大可以表示十萬億級別的數據，DECIMAL(14,2)不建議，千億級別不夠玩
* 金額利率字段建議DECIMAL(10,6)的數據類型，小數點后保留6位，對應金額的計算是準確的，我多年的經驗，一般展示會展示4位利率，這個業務層處理下就好
#### 7. 根據業務選擇字段類型規范、默認值規范
* 一般擴展性有限的常量類型，建議用整形，性能高，占空間少，比如狀態字段，初始設置值的時候，建議1,3,5,7這樣，方便擴展
* 一般不確定擴展性的類型，建議用字符型，若訂單子類型，字符型的好處，可以添加業務規則，一個字段可以同時表示出爺爺，兒子孫子的含義，比如
* subType=0000 0000 0000 前四個字段代表大類購買類型，中間代表子類購買，最后代表三級購買類型，這樣通過一個字段可以做很多事情
* 序列號，id等字段，建議varchar(32)或者bigint
* 如果未了方便查問題，且表的數據量不大，可以用有含義的英文單詞表示常量，比如收入IN， 支出OUT， 數據庫查下排查問題很方便
* 不要有null值，不要有null值，不要有null值，建表是要default 一個默認值，盡量建表是not null語句，
* 除了modify_time必須default null以外，其他都是not null
#### 8. 默認建表存在的字段規范
* 一個表必須要有的默認字段，這些字段可以排查問題，做變更記錄，方便BI數據統計等
* 同事注意create_time一定要加索引，真的要加，要加
* `create_time` datetime NOT NULL COMMENT '表創建時間',
* `modify_time` datetime DEFAULT NULL COMMENT '表修改時間',
* `remark` varchar(64) DEFAULT NULL COMMENT '備注',
* create_time和modify_time建議在daoimpl層做時間處理，可以完全保證準確沒有臟數據，防止被誤用
對于后臺操作的系統，還需要有的字段
operator 操作人 operate_time 操作時間 等
對于事務要求強的業務表和一些變更記錄表，需要有的字段
version 版本號 seq序列號
#### 9. 主鍵ID規范
* 每個表都應該設置一個ID主鍵，最好的是一個INT型，并且設置上自動增加的AUTO_INCREMENT標志，這點其實應該作為設計表結構的第一件必然要做的事！！
* 個人強烈建議：自增id主鍵+全局唯一序列號， 全局唯一序列號(必須加唯一索引)
* 100xxxxxx-廣東省, 200xxxxxx-黑龍江
* 遍歷需求的對于自增ID的表來說很容易實現
主鍵設計：
1.自增id， bigint
2.15位時間戳+業務標志+rand 32 (TSS可以生成全局唯一主鍵)，生成業務含義全局唯一主鍵，可以模仿訂單服務ID生成器
3.分布式全局唯一， UUID或額外系統主鍵生成系統支持
#### 10. 冪等性支持規范
冪等性處理方法，可以找，技術開發中的坑，這個ppt里面有，在wiki
如果數據表中記錄在某個字段下或字段組合下是唯一的，需要加唯一索引，防止臟數據生成
對外接口冪等性，設置source+seq兩個字段為唯一索引再數據庫中，保證冪等
#### 11. 索引設計規范
#### 原則：
* 根據業務需求設計索引
* 索引不要過多，影響插入更新性能
* 一個字段的值范圍很小，不要設置索引，索引不生效同事浪費插入性能
* 如果有冪等性需求，設置數據庫唯一索引
* null值對索引是一大傷害，所以不要讓索引的列有null值存在
* 盡量加索引的字段的數據類型小，也就是能用整數不用varchar能用短的varchar不用長的varchar，不要在text上設置索引
#### 例子
如賬戶，userId設置為唯一索引，一個人只能有一個銅板賬戶
收支流水表的userID設置普通索，查詢效率高
create_time 默認加索引。。。。
a,b,c 組合索引，索引構建是用a+b+c進行構建的索引，如果是btree索引，查詢的時候 abc|ab|a三種查詢條件都會走索引
不需要對a和ab重復創建索引 ，但是 like '%b'|'%bc'|'%c'不會走索引，所以，組合索引，一定使用頻率高的放在最左邊
#### 12. 數據加密規范
* 哪些字段需要加密？
* 敏感字段，如姓名，身份證號，銀行卡號，郵箱等
* 加密算法選擇？對稱還是非對稱？
* 根據實際業務進行選擇，可以MD5，可以RSA，可以AES，具體選擇后續，老夫出個介紹算法的
* 字段長度選擇？
* 字段長度要根據業務長度加密后長度進行設定，如果過長要選擇換加密算法等
#### 13. 注釋規范
* 每個字段要有注釋
* 每個表名要有注釋
* 字段的取值含義或者范圍，枚舉值要有注釋
* 總之：看建表語句，看的爽，就對了
#### 14. 表字段順序規范
* 你沒有看錯，是這個，表的字段順序很重要
* 從前到后，按照字段的重要性和使用頻率排列。
* 按字段的分類歸集排列：如 金額相關的在一塊，文案相關的在一塊，時間相關的在一塊等
* create_time,modify_time,remark三個字段在最后
#### 15. 數據庫引擎的選擇
Innodb，沒的商量，就是這個，原因就一條，我們做的是金融行業，安全、安全、安全
必須選用innodb理由
1 Innodb支持事務，數據庫崩潰恢復穩定
2 支持在線備份，方便運維工作
3 官方版本致力于優化innodb，后期功能和穩定性會越來越好
4 支持行鎖，支持mvcc
#### 16. 如何防止全表掃描
#### 原則：
* 全表掃描會造成數據庫掛掉,OOM,慢查詢等可怕事情
* 索引的值范圍很少，索引即使設計了也不會生銹，也會全表掃描
* 刪數據時，where后必須有條件，條件走索引，同時加limit限制，防止sql錯誤，多刪數據
**會出現全表掃描的情況，如下**
* 未創建索引 例如： select * from tbname where name='?' 如果name字段未創建索引，那么就是全表掃描
* 隱式轉換 例如：select * from tbname where id=1234; 如果id字段是varchar類型，那么就算id字段上建立有索引，也還是會走全表掃描。
* 索引區分度問題：select * from tbname where status=1 and name=？ ,status,sex這類字段的重復值過低，索引區分度超過30以上，
* 優化器會認為status索引效率低，如果name字段沒有索引的話，就會全表掃描
* 索引字段上使用函數 select * from tbname where date(create_time)=? create_time字段上使用了函數，將不會走索引，可以改成 create_time=date_format(?)這種形式
* 聯合索引字段順序， a,b字段創建聯合索引，select * from tbname where b=? 不符合左前綴原則， 單獨使用b字段無法使用索引，可改成 index(b,a);
**防止全表掃描的辦法**
DAOIMPL層面限制不走索引的查詢sql
DAOIMPL層面限制索引值少的查詢sql
mybatis.xml層面對刪除進行限制Delete from tb_position where id=142343 limit 1;
下面的例子，大家可以借鑒下哈，哈哈哈哈，注意是對數量和索引的限制，防止慢查詢和OOM
#### 17. 如何遍歷
**有自增主鍵的遍歷**
select * from table_xxx where status = #status and id > #lastQueryId limit 1000;
優點：性能高，不漏數據，遍歷數據狀態變更不會造成位移，每次取出最后一條ID，進行下一次查詢，性能極高，屌屌的
缺點：暫時沒發現
是否是帶狀態更新的遍歷：
會可能存在位移差，存在漏數據
**解決辦法：**
1. id>#lastId, limit 100, order沒有自增主鍵
2. Create_time 索引， create_time>=#lastCreateTime, limit 100;支持冪等
3. 存在新增數據的遍歷，做臨時表，臨時表做業務重復判斷。
4. create_time 半開查詢 create_time >= egtCreateTime and create_time<ltCreateTime
#### 18. 如何分表
深入理解業務，根據業務特性來分表，根據查詢需求來分表
案例：
1.代金券分表 （季度分）
2.每日收益分表 （userId取余）
3.對賬分表 （按月分）
4.微信紅包分表 （年度+用戶分）
