Schema設計

---

Schema：表的模式； 設計數據的表，索引，以及表和表的關系

在數據建模的基礎上將關系模型轉為數據庫表

滿足業務模型需要基礎上根據數據庫和應用特點優化表結構

關系模型圖：

?

Schema關系到應用程序功能與性能

• 滿足業務功能需求
• 同性能密切相關
• 數據庫擴展性
• 滿足周邊需求（統計，遷移等）

關系型數據庫修改Schema經常是高危操作 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位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的schema设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。