schema设计
Schema設計
Schema:表的模式; 設計數據的表,索引,以及表和表的關系在數據建模的基礎上將關系模型轉為數據庫表 滿足業務模型需要基礎上根據數據庫和應用特點優化表結構 關系模型圖:
? 1 反范式,冗余必要字段 2 拆分大字段
?
Schema:表的模式; 設計數據的表,索引,以及表和表的關系
?
Schema關系到應用程序功能與性能- 滿足業務功能需求
- 同性能密切相關
- 數據庫擴展性
- 滿足周邊需求(統計,遷移等)
- 著眼于實現當前功能
- 完全基于功能的設計可能存在一些隱患
-
- ?? 不合理的表結構或索引設計造成性能問題
- ?? 沒有合理評估到數據量的增長造成空間緊張而且難以維護
- ?? 需求頻繁修改造成表結構經常變更
- ?? 業務重大調整導致數據經常需要重構訂正
- 根據查詢需要設計好索引
- 根據核心查詢需求, 適當調整表結構
- 基于一些特殊業務需求,調整實現方式
- 正確使用索引
- 更新盡可能使用主鍵或唯一索引
- 主鍵盡可能使用自增ID字段
- 核心查詢使用覆蓋索引
-
- ? ? ? ? ? 用戶登錄需要根據用戶名返回密碼用于驗證
- ? ? ? ? ? create index idx_uname_passwd on tb_user (username,passwd);
- ? ? ? ? ? 建立聯合索引避免回表取數據
? 1 反范式,冗余必要字段 2 拆分大字段
?
3 避免過多字段或過長行 4 分頁查詢: 5 ?熱點讀數據特殊處理 6 熱點寫數據特殊處理?
7 準實時統計?
實時統計改進1--觸發器實時統計?
實時統計改進2-緩存實時統計?
實時統計改進3-最大自增ID獲取總數?
? 8 ?可擴展性設計?
9 分區表與數據淘汰 range分區?
list分區?
hash分區 10 滿足周邊需求 統計和后臺需求 11 自動更新時間戳 Schema設計與前瞻性- 基于歷史經驗教訓,預防和解決同類問題
- 把折騰DBA夠嗆的索引Schema改造的原因記錄并分析總結
- ?數據庫結果大量改動,增加了加密字段,驗證策略表,所有表重新訂正數據等等
- ?是否所有用到用戶信息管理的應用都要去上線就用密文?
?
?總結?
- ?schema設計關系性能
- ?反范式,冗余必要字段
- ?拆分大字段
- ?避免過多字段或過長字段
- ?分頁查詢
- ?熱點讀數據特殊處理:置頂表與普通表分開
- ?熱點寫數據特殊處理:
-
- 微博普通用戶發消息,則寫入關注他的人的消息列表中;微博大V發消息,則關注他的人都去讀他的消息列表;
- ?準實時統計:
-
- 定時統計表,更據上次更新時間統計全表中增量sum值,每分鐘更新統計表;
- ?實時統計:
-
- 觸發器實時統計,在用戶插入時,更新統計表;
- 緩存實時統計,應用將用戶新增寫在內存緩存中,業務平時從緩存中讀,緩存失效,從數據庫做一次查詢,接著寫在緩存;
- 分區表與數據淘汰
- 滿足周邊需求:
-
- 如后臺統計任務而增加特殊索引,
- 為數據遷移或統計增加時間戳
- 自動更新時間戳
- schema設計與前瞻性
轉載于:https://www.cnblogs.com/Aiapple/p/5694327.html
《新程序員》:云原生和全面數字化實踐50位技術專家共同創作,文字、視頻、音頻交互閱讀總結
- 上一篇: 生成元(Digit Generator
- 下一篇: 只读账号设置-db_datareader