-
如何維護索引
如何選擇合適的列建立索引
1、出現在where從句 group by 從句 order by 從句中的列
2、可選擇性高的列要放到索引的前面
3、索引中不要包括太長的數據類型
注意事項
1、索引并不是越多越好，過多的索引不但會降低寫效率而且會降低讀的效率
2、定期維護索引碎片
3、在sql語句中不要使用強制索引關鍵字
如何維護表結構
1、使用在線變更表結構的工具
mysql5.6之后本身支持在線表結構的變更
2、同時對數據字典進行維護
3、控制表的寬度和大小
數據庫中適合的操作
1、批量操作VS逐條操作
2、禁止使用select * 這樣的查詢
3、控制使用用戶自定義函數
4、不要使用數據庫中的全文索引
表的垂直拆分
為了控制表的寬度可以進行表的垂直拆分；
1、經常一起查詢的列放在一起；
2、text,blob等大字段拆分出到附加表中
表的水平拆分
為了控制表的大小可以進行表的水平拆分
hash key 取模 等分表
查看全部 -
反范式化
所謂反范式化就是為了性能和讀取效率的考慮而適當的對第三范式的要求進行違反，而允許存在的少量的數據冗余
反范式化就是使用空間來換取時間；
為什么要反范式化
1、減少表的關聯數量
2、增加數據的讀取效率
3、反范式化一定要適度
查看全部 -
如何選擇主鍵
1、區分業務主鍵和數據庫主鍵
業務主鍵用于標識業務數據，進行表與表之間的關聯；
數據庫主鍵為了優化數據存儲（Innodb會生成6個字節的隱含主鍵）
2、根據數據庫的類型，考慮主鍵是否要順序增長
有些數據庫是按主鍵的順序邏輯存儲的
3、主鍵的字段類型所占空間要盡可能的小；
對于使用聚集索引方式存儲的表，每個索引后都會附件主鍵信息；
避免使用外鍵約束
1、降低數據導入的效率
2、增加維護成本
3、雖然不建議使用外鍵約束，但是相關聯的列上一定要建立索引
避免使用觸發器
1、降低數據導入的效率
2、可能會出現意想不到的數據異常
3、使業務邏輯變的復雜
關于預留字段
1、無法準確的知道預留字段的類型
2、無法準確的知道預留字段所存儲的內容
3、后期維護預留字段所要的成本，同增加一個字段所需要的成本是相同的
4、嚴禁使用預留字段
查看全部 -
表及字段的命名規則
1、可讀性原則
使用大寫和小寫的格式化的庫對象名字以獲取良好的可讀性；
使用CustAddress 而不是customeraddress來提高可讀性
2、表意性原則
對象的名字應該能夠描述它所標識的對象
如：對于表，表的名稱應該能體現表中存儲的數據內容；
對于存儲過程，存儲過程名稱應該能夠體現存儲過程的功能；
3、長名原則
盡可能少使用或者不使用縮寫，適用于數據（DATABASE）名之外的任一對象；
字段類型的選擇原則
1、在數據進行比較（查詢條件、join條件及排序）操作時：同樣的數據，字符處理往往比數字處理慢
2、在數據庫中，數據處理以頁為單位，列的長度越小，利于性能提升
char和varchar如何選擇
1、如果列中要存儲的數據長度差不多是一致的，則應該考慮用char; 否則應該考慮用varchar；
2、如果列中的最大數據長度小于50byte，則一般也考慮用char；
3、一般不宜定義大于50byte的char類型列；
decinal與float如何選擇
1、decimal用于存儲精確數據，而flot只能用于存儲非精度數據，故精確數據只能選擇用decimal類型；
2、由于flot的存儲空間開銷一般比decimal小，故非精確數據優先選擇flot類型
時間類型如何存儲
1、使用int來存儲時間字段的優缺點：
優點：字段長度比datetime小
缺點：使用不方便，要進行函數轉換
限制：只能存儲到2038-1-19 11:14:07
2、需要存儲的時間顆粒
年 月 日 時 分 秒 周
查看全部 -
表及字段的命名規則
1、可讀性原則
使用大寫和小寫的格式化的庫對象名字以獲取良好的可讀性；
使用CustAddress 而不是customeraddress來提高可讀性
2、表意性原則
對象的名字應該能夠描述它所標識的對象
如：對于表，表的名稱應該能體現表中存儲的數據內容；
對于存儲過程，存儲過程名稱應該能夠體現存儲過程的功能；
3、長名原則
盡可能少使用或者不使用縮寫，適用于數據（DATABASE）名之外的任一對象；
字段類型的選擇原則
1、當一個列可以選擇多種數據類型時，應該優先考慮數字類型，其實是日期或二進制類型，最后是字符串類型。
2、對相同級別的數據類型，應該優先選擇占用空間小的數據類型
3、在數據庫進行比較（查詢條件、JOIN條件及排序）操作時：
同樣的數據，字符處理往往比數字處理慢；
4、在數據庫中，數據處理以頁為單位，列的長度越小，利于性能提升；
查看全部 -
Boyce.Codd范式（BCNF）
定義：在第三范式的基礎之上，數據庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數依賴則附合BC范式；
也就是說如果是復合關鍵字，則復合關鍵字之間也不能存在函數依賴關系；
查看全部 -
第二范式（2NF）
存在的問題：
1、插入異常
2、刪除異常
3、更新異常
4、數據冗余
第三范式（3NF）
定義： 第三范式是在第二范式的基礎之前定義的，如果數據表中不存在非關鍵字段，對任意候選關鍵字段的傳遞函數依賴則符合第三范式；
（商品名稱）->（分類）-> （分類描述）
也就是說存在非關鍵字段 '分類描述'對關鍵字段'商品名稱'的傳遞函數依賴；
存在問題：
（分類、分類描述）對于每個商品都會進行記錄，所以存在著數據冗余。同時也還存在數據的插入，更新及刪除異常
查看全部 -
第一范式（1NF）
定義：數據庫表中所有字段都是單一屬性，不可再分的；
第一范式要求數據庫的表都是二維表
第二范式（2NF）
定義：數據庫的表中不存在非關鍵字段對仁義候選關鍵字段的部分函數依賴；
查看全部 -
數據庫操作異常
查看全部 -
數據庫建立的1步驟
查看全部 -
表的水平拆分
查看全部 -
表的垂直拆分
查看全部 -
字段類型選擇原則
查看全部 -
字段類型的定義
查看全部 -
ＭySQL常用存儲引擎
查看全部
舉報