終於來到資料庫設計的最後一步，前面說到的邏輯分析、物理設計是建立資料庫必須經歷的，這麼看來資料庫的維護以及優化似乎就沒有那麼重要，自然，如果你滿足於自己的系統永遠被少數人使用，不會慢慢壯大，那你的專案的確不需要做必要的優化措施，但在專案需求會在使用人數的壯大，功能的增強中不斷變化，那資料庫的結構自然也需要相應的變化才能適用。
那麼資料庫優化需要做些什麼呢？下面是我們比較常做的資料庫優化的操作。
維護資料字典
資料字典是對資料庫中的表、字段甚至是處理邏輯的定義和描述，簡單來說，就是資料庫的注釋，它可以讓我們清楚了解資料庫中每乙個列，每乙個字段表示的內容是什麼，其中我們經常使用數字表示某個狀態，如果沒有資料字典清楚的描述清楚，那我們維護這些欄位就會變得十分困難，我就嘗試過需要在**中尋找對應的數字所表示的狀態，十分耗時耗力。
維護資料字典最常見的方法自然還是使用備註來維護，以 mysql 為例，它可以對資料庫、表、字段增加備註字段，之後我們匯出資料結構的時候就可以作為我們的資料字典來使用了。
當然我們也可以用第三方工具來維護資料字典，但不同的資料庫系統需要找對應的第三方工具，相對來說比較麻煩，不推薦。
索引的維護
資料庫的索引是能讓你做資料庫查詢時快速查到自己想要的資料的利器，當你面對著千萬級別的資料做查詢的時候你就能清楚的感受到好的索引設計是多麼的必要了。而因為需求的變化，我們之前建立的十分適用的索引也會變得越來越不適用，所以索引的維護也是資料庫維護中十分重要的一塊。
當然索引作為很好用的工具，其中包含著十分多的知識點，是乙個很大的話題，所以這裡就簡單說明下怎樣建立索引比較合適，想要深入的可以從索引的工作原理開始了解，會給你帶來不小的啟發。
以下是建立合適索引需要注意的點
1.較頻繁的作為查詢條件字段應該建立索引（where、group by、order by 從句中的列）
2.唯一性太差的字段不適合單獨建立索引，即使頻繁作為查詢條件，例如性別欄位等
3.更新非常頻繁的字段不適合建立索引（字段內容，例如狀態）
4.索引中不要包含太長的資料型別
還有一些需要注意的點
這裡提供乙個小小的方法，在執行某個 sql 查詢時，可以在查詢語句前加入explain 關鍵字，它可以讓我們看到我們是否在查詢時用上索引。
表結構的維護
乙個專案功能的變更往往會導致資料庫表的列的變更，所以對變更後的表結構進行維護也是十分必要的，表結構的維護分為以下幾個步驟。
表結構變更後記得更新資料字典
控制表的寬度（列的多少）和大小
進行表拆分
表的拆分分為垂直拆分和水平拆分，簡單來說，當乙個表的列太大的情況下，需要考慮垂直拆分，當乙個表的資料量太大的情況，需要考慮水平拆分。
1.垂直拆分
垂直拆分的主要目的就是控制表的寬度，正常情況下，乙個表的列達到幾十列的情況下，我們就要考慮表的垂直拆分。
垂直拆分
垂直拆分可以根據以下的兩點去拆分
2.水平拆分
當乙個表的資料量達到千萬級別，我們就需要考慮表的水平拆分，簡單來說就是把一張表複製成多份，每乙份儲存的資料不同。
水平拆分
比較常見的是通過主鍵雜湊的方式
主鍵雜湊
我們可以先確定將大表拆分為幾個小的表，例如拆分為5個表，則 id=103 的資料 103%5=3，可以將這個資料放到表2中（因為餘數為0的是表1），這樣就可以做到將資料平均的放到各個表中了。
當然還有一些訂單資料可以通過時間拆分，因為時間較久的訂單往往比較少進行查詢，將此類訂單與近期常用到的訂單拆分開來也比較方便查詢。
資料庫update死鎖
比較常見的死鎖場景，併發批量update時的乙個場景 update cross marketing set gmtmodified now pageview pageview extpageview where marketingid marketingid 第一次呼叫時，marketingid傳入...
資料庫學習 update（批量更新）
資料更新update命令 用指定要求的值更新指定表中滿足天劍的資料的指定列的值 語法形式 update 表名 set 列名 表示式 子查詢 列名 表示式 子查詢 where 條件表示式 示例 1 將所有教師工資上調 10 原表資料 執行兩次後結果 2 將所有計算機學院的老師工資上調 10 updat...
資料庫 資料庫設計正規化
在關聯式資料庫中的關係是要滿足一定要求的，滿足不同程度要求為不同正規化，越高的正規化資料庫冗餘越小。但是有些時候一昧的追求正規化減少冗餘，反而會降低資料讀寫的效率，這個時候就要反正規化，利用空間來換時間。目前關聯式資料庫有六種正規化 第一正規化 1nf 第二正規化 2nf 第三正規化 3nf 巴斯 ...