資料庫建表規範(摘自rrc-wiki)
1 基礎要求
以下為一般業務場景的通用要求
1.1 使用innodb引擎,字符集編碼為UTF-8;
1.2 有自增主鍵,型別建議為bigint;
1.3 表資料的增刪改,不使用並且依賴外來鍵,觸發器,儲存過程;
1.4 非空約束必須為not null;
2 欄位要求
2.1 不使用enum列舉型別,可用int,varchar等替代;
2.2 精確的數值計算使用decimal型別;
2.3 字元小於255並且長度較固定時,使用char型別,其它情況使用varchar型別;
2.4 時間欄位,createtime updatetime等unix時間戳欄位直接使用int型別,日期優先使用timestamp型別,需要較大時間跨度的情況下再使用datetime;
createtime updatetime不推薦使用int型別,可讀性太差,除非效能可能成為瓶頸
3 索引要求
3.1 索引根據實際情況優化,原則上索引的數量不超過欄位數的20%;
3.2 根據索引覆蓋,最左原則等原則建索引;
3.3 有唯一語義的情況下使用uniqe索引;
3.4 區分度不高的情況下,不必建索引(依據:過濾後的結果集/總量 > 1/10)
- 例如:需要查詢某個電話從某個product進來的線索詳情,只需要在phone建索引,不需要phone+product的聯合索引,因為product區分度低
4 變更要求
對於已經上線的表進行變更時要考慮對線上業務的影響;
4.1 所有的表結構的操作都需要線上下進行測試;(通過阿里雲建立臨時庫,進行測試,估計執行時間)
4.2 對於牽涉到刪除索引的操作,需要確認索引缺失可能造成的查詢效能下降;
4.3 對於小表(10萬行以下),可以確認後執行;
4.4 對於大表,必須在低峰期(上午9點前或者凌晨)執行,推薦凌晨執行,出現故障影響更可控;
4.5 對於確定的執行時間超過10分鐘並且會造成鎖表的,推薦使用 建立新表,同步舊錶資料,rename的方式來更新;
CREATE TABLE `rrc_order`.`cm_user_c2_intent_20160912` LIKE `rrc_order`.`cm_user_c2_intent`; ALTER TABLE `rrc_order`.`cm_user_c2_intent_20160912` CHANGE COLUMN `created_at` `created_at` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '記錄生成時間|陳沛鑫|2016-09-17' , CHANGE COLUMN `updated_at` `updated_at` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '記錄變更時間|陳沛鑫|2016-09-17' , ADD INDEX `update_time_index` (`updated_at` DESC); INSERT INTO `rrc_order`.`cm_user_c2_intent_20160912` SELECT * FROM `rrc_order`.`cm_user_c2_intent`; INSERT INTO `rrc_order`.`cm_user_c2_intent_20160912` SELECT * FROM `rrc_order`.`cm_user_c2_intent` WHERE `id` > (SELECT MAX(`id`) FROM `cm_user_c2_intent_20160912`); RENAME TABLE `rrc_order`.`cm_user_c2_intent` TO `rrc_order`.`cm_user_c2_intent_temp`, `rrc_order`.`cm_user_c2_intent_20160912` TO `rrc_order`.`cm_user_c2_intent`, `rrc_order`.`cm_user_c2_intent_temp` TO `rrc_order`.`cm_user_c2_intent_20160912`; |
4.6、其他tips:
操作前確保有dms的連線在,防止出現問題時連線被佔滿,無法連線資料庫;
如果操作中出現故障,儘量將流量先從故障例項切走(例如從庫出現問題,可以把讀請求都切到主庫),再進行故障分析;
5 大資料建表規範
6 參考文件
其他細節可以參考編寫指南,大部分情況下適用。
連結: https://pan.baidu.com/s/1OE3SQrB1BmGSHDiCGcwzwQ 密碼: mn4s