結合dbms(資料庫管理系統)實現有效儲存、高效訪問。減少資料冗餘，避免維護異常，節約儲存空間。
需求分析->邏輯設計->物理設計(考慮資料庫系統的差異)->維護優化(新需求建表，索引，拆分)。
理清楚實體及實體之間的關係(一對一，一對多，多對多)，實體包含的屬性，哪些屬性(或者屬性組合)可以唯一標識乙個實體
如果資料庫表中的所有字段值都是不可分解的原子值，就說明該資料庫表滿足了第一正規化。第一正規化要求資料庫中的表都是二維表
就比如說，如果有乙個表的列名是籍貫，裡面儲存的資料是廣東廣州等等，好了那麼這裡有乙個問題，查詢的時候，我要怎麼查所有籍貫是廣東省的？或許可以用模糊查詢，但是這不是最好的解決辦法，如果是只查廣東廣州呢？如果別的省份也有廣州呢？
所以說最好的解決辦法是把省份和城市分開。
資料庫的表中不存在非關鍵字段對任意候選關鍵字段的部分函式依賴。
第二正規化需要確保資料庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。也就是說在乙個資料庫表中，乙個表中只能儲存一種資料，不可以把多種資料儲存在同一張資料庫表中。
所有單關鍵字段的表都符合第二正規化
對於某些多對多關係的表，需要分開儲存並且使用外來鍵關聯。
第三正規化需要確保資料表中的每一列資料都和主鍵直接相關，而不能間接相關。
第二正規化的基礎上解決了傳遞依賴
在第三正規化的基礎之上，資料庫表如果不存在任何欄位對任意候選關鍵字段的傳遞函式依賴則符合bc正規化。
確保資料表中的每一列資料都和主鍵和候選關鍵字直接相關，而不能間接相關
主流的有myisam和innodb
不支援事務處理，併發插入的表級鎖，一般不用於頻繁讀寫。
mvcc行級鎖，適用於大部分情況。
- 可讀性原則
使用大小寫，某些資料庫系統對大小寫敏感。
- 表意性原則
名稱應該表示功能
- 長名原則
盡量使用全名
列的資料型別一方面影響了資料儲存空間的開銷，另一方面也會影響資料查詢效能。當乙個列可以選擇多種資料型別的時候
- 首先考慮數字型別
- 其次考慮日期或者二進位制型別
- 最後是字元型別
- 相同級別的資料應該優先選擇占用空間小的，比如char varchar 之間應該選擇varchar
原因：- 資料進行比較(查詢、join、排序)時，相同資料，字元處理比數字慢
- 在資料庫中，資料處理以頁為單位，列的長度越小，利於效能提公升。
char 和 varchar
1. 列中資料長度差不多的應該考慮char
2. 列中資料長度小於50 byte一般也用char。(列很少用除外，為了節省空間和減少io，還是應該考慮varchar)
3. 一般不宜定義大於50 b的char
decimal和float
1. decimal(8個位元組)儲存精確資料
2. float開銷小(4個位元組)
時間型別
- int儲存
字段長度比datetime小，但是使用不方便，要函式轉換。只能儲存到2038-1-19。
- 時間粒度
考慮時間粒度選擇適合的型別值
1. 業務主鍵和資料庫主鍵
業務主鍵用於標識業務資料，進行表與表之間的關聯。
資料庫主鍵為了優化資料儲存
innodb會預設生成6位元組的隱含主鍵，所以盡量自定義主鍵提高儲存效率
2. 根據資料庫型別，考慮逐漸是否要順序增長
有些資料庫是按主鍵順序邏輯儲存的
3. 主鍵字段型別占用空間要盡可能小。
對於使用聚集索引方式儲存的表，每個索引猴都會附加主鍵資訊
- 降低資料匯入效率
- 可能出現意想不到的資料異常
- 使業務邏輯變得複雜
- 無法準確知道預留欄位的型別
- 無法準確知道所儲存的內容
- 後期維護字段成本和增加字段成本相同
嚴禁使用預留字段
通過資料冗餘增加訪問效率，簡化查詢語句。空間換取時間。
- 減少關聯表數量
- 增加讀取效率
- 要適度
- 可以增加表或者欄位的備註
- 經常查詢的列要加索引，索引不要包括太長的資料型別
- 過多的索引會降低讀和寫的效率，所以要定期維護索引碎片，sql語句中不要使用強制索引關鍵字。
- 變更表結構控制表的寬度和大小，同時對資料字典進行維護
- 盡量不使用select *
- 控制使用者使用自定義函式
- 不要使用全域性索引
垂直拆分
- 經常查詢的列放到一起
- text, blob等大字段拆分到另一附加表中
水平拆分
- 通過主鍵雜湊平均分成幾分
MySQL的優化細節
結合dbms 資料庫管理系統 實現有效儲存 高效訪問。減少資料冗餘，避免維護異常，節約儲存空間。需求分析 邏輯設計 物理設計 考慮資料庫系統的差異 維護優化 新需求建表，索引，拆分 理清楚實體及實體之間的關係 一對一，一對多，多對多 實體包含的屬性，哪些屬性 或者屬性組合 可以唯一標識乙個實體 如果...
優化小細節
1 當使用索引列進行查詢的時候見諒不要使用表示式，把計算放到業務層而不是資料庫層 select id from table where id 1 5 優先順序範圍為ref select id from table where id 4 優先順序範圍為count 2 盡量使用主鍵查詢，而不是其他索引，...
SEO成功在細節 URL細節優化
我們在做 優化時，肯定也遇到過url的優化，大家可以先看看這兩篇文章，再看本文。1 url的描述性 整個url包括網域名稱，目錄名和檔名，在可能的情況下，用具有描述性的單詞，尤其是目錄名和檔名。讓使用者看到url，就可以大致了解這個網頁是什麼內容。3 網域名稱的選擇 4 保證url長度的合理性 5 ...