辛星讓mysql跑的更快第一節之最佳化的方向和資料庫建模，辛星讓mysql

辛星讓mysql跑的更快第一節之最佳化的方向和資料庫建模，辛星讓mysql

    最近計劃寫一套書目，也就是關於mysql的最佳化的，那麼首先在部落格上寫寫，然後整理成pdf的文檔的形式，當然也期待各位的關注了。對於mysql的最佳化是一個比較大的話題，可最佳化的地方也很多，大致想了一下，可以從這些地方下手。

     首先就是硬體層次，包括選擇合適的作業系統、選擇合適的硬體，然後就是源碼層次，不過雖然mysql是開源的，但是能夠修改其原始碼的公司雖然不少，但是也沒有那麼多，但是我們可以選擇更加合適的編譯器重新編譯其原始碼，然後就是設計到表的設計，也就資料庫建模。

     其次可以考慮使用一些其他技術，比如讀寫分離和分表技術，或者使用叢集技術，這要求我們從整體上去構架。對於具體的內容，我們可以採用設定索引、最佳化sql查詢語句、定期表修複、使用預存程序等等。

     這裡我們先說說資料庫建模這部分，這部分往往和和商務邏輯有關係，通常來說新手都喜歡死扣第三範式或者BC範式，如果更要求完美，可能會死扣第五範式，其實高手也都是這麼一步步過來的，那麼我們先介紹一下什麼是第三範式。

       第一範式就是對屬性的原子性約束，也就是說表的列具有原子性，不能再次分割，它的約束性真的很低，只要資料庫是關係型資料庫，就會自動滿足第一範式了，那麼哪些可能會不滿足第一範式呢？如果我們儲存了一個集合，儲存了一個數組，那麼這就不滿足第一範式了，但是對於關係型資料庫，不可能出現這種情況，我們無法向裡面儲存一個數組。注意，這裡說的是儲存了一個集合，而不是集合中的元素。

      第二範式就是屬性完全依賴於主鍵，舉個例子，加入我們建立一個People表，它裡面可以寫一個欄位是社會安全號碼，那麼由於每個人的社會安全號碼都不是不重複的，這個人的資訊也會由這個人的社會安全號碼唯一決定，這就可以可以理解為一個主鍵，這裡的社會安全號碼是主鍵，但是姓名並不是主鍵，因為重名的情況還是挺多的。它的目的是為了防止資料的重複，因此我們使用一個主鍵來唯一的標識一條記錄。需要注意的是，主鍵並不一定必須是一個欄位，比如說有時候兩個資訊才能確定一條記錄，比如在一個檔案夾下面的檔案名稱和尾碼名這兩個才能確定一個唯一的檔案名稱，我們分開來存放資訊的話，這兩個欄位就構成了它的主鍵。值得注意的是，我們通常用一個數字類型的自增的id來作為主鍵，但它不是必須的。

       第三範式的要求就更加苛刻了，它要求表中不要有冗餘資料，那它的規範就是說：任何非主鍵的屬性都必須依賴於主鍵，但是不能傳遞依賴於主鍵。舉個超經典的例子，這也是我在學習第三範式的時候的例子，因為它太經典了，我可能一輩子都忘記不了。比如說我建立了一個表，它的欄位資訊如下：（學號，學生姓名，學生所在系名，學生所在系的地址）,猛一看這個表也沒什麼問題，但是它會產生冗餘資訊，那就是學生所在系的地址這一個屬性也是由學號唯一確定的，但是它不是直接依賴的，它是傳遞依賴的，它直接依賴與系名，而不是學生的學號，因此，我們會發現，對於不同的學號，會導致儲存很多一樣的系名，這就是所謂的冗餘資訊。

     那麼我們怎麼修改呢，答案就是分表，注意，我們還必須遵循第二範式，我們可以增加一個系的編號這麼一個欄位，即第一個表資訊（學號，學生姓名，所在系編號），第二個表（系編號，系名，系的地址），這麼一來，我們就不會儲存冗餘資訊了，這就是第三範式所帶來的效果。

     除了第三範式之外，還有一個也很重要，叫做BC範式，也就是著名的巴斯-科德範式，它的要求是什麼呢？它是對主鍵的要求，也就是主碼，它要求，主碼的任何一個真自己都不能唯一的確定這個主碼，什麼意思。比如說我把學生的社會安全號碼和學號這兩個合起來 設計為主鍵，它並不違反第三範式，但是它違反了BC範式，原因何在呢？因為在一個學校裡，任何兩個學生的社會安全號碼和學號都不相同，也就是說，我們使用學號作為主鍵或者社會安全號碼作為主鍵都可以，但是使用這兩個一起作為主鍵，沒必要。

      我不知道讀者是否暈了，大體思路就是這樣，其實這些範式都是人做出來的，也不難理解，我這裡並沒有引入太多的邏輯符合和專業術語，算是用比較平常的語言來敘述，也是希望更好理解，如果您有什麼問題，可以在下面留言給我。