最近計劃寫一套書目，也就是關於mysql的優化的，那麼首先在博客上寫寫，然後整理成pdf的文檔的形式，當然也期待各位的關注了。對於mysql的優化是一個比較大的話題，可優化的地方也很多，大致想了一下，可以從這些地方下手。
首先就是硬件層次，包括選擇合適的操作系統、選擇合適的硬件，然後就是源碼層次，不過雖然mysql是開源的，但是能夠修改其源代碼的公司雖然不少，但是也沒有那麼多，但是我們可以選擇更加合適的編譯器重新編譯其源代碼，然後就是設計到表的設計，也就數據庫建模。
其次可以考慮使用一些其他技術，比如讀寫分離和分表技術，或者使用集群技術，這要求我們從整體上去構架。對於具體的內容，我們可以采用設置索引、優化sql查詢語句、定期表修復、使用存儲過程等等。
這裡我們先說說數據庫建模這部分，這部分往往和和業務邏輯有關系，通常來說新手都喜歡死扣第三范式或者BC范式，如果更要求完美，可能會死扣第五范式，其實高手也都是這麼一步步過來的，那麼我們先介紹一下什麼是第三范式。
第一范式就是對屬性的原子性約束，也就是說表的列具有原子性，不能再次分割，它的約束性真的很低，只要數據庫是關系型數據庫，就會自動滿足第一范式了，那麼哪些可能會不滿足第一范式呢？如果我們存儲了一個集合，存儲了一個數組，那麼這就不滿足第一范式了，但是對於關系型數據庫，不可能出現這種情況，我們無法向裡面存儲一個數組。注意，這裡說的是存儲了一個集合，而不是集合中的元素。
第二范式就是屬性完全依賴於主鍵，舉個例子，加入我們創建一個People表，它裡面可以寫一個字段是身份證號，那麼由於每個人的身份證號都不是不重復的，這個人的信息也會由這個人的身份證號唯一決定，這就可以可以理解為一個主鍵，這裡的身份證號是主鍵，但是姓名並不是主鍵，因為重名的情況還是挺多的。它的目的是為了防止數據的重復，因此我們使用一個主鍵來唯一的標識一條記錄。需要注意的是，主鍵並不一定必須是一個字段，比如說有時候兩個信息才能確定一條記錄，比如在一個文件夾下面的文件名和後綴名這兩個才能確定一個唯一的文件名，我們分開來存放信息的話，這兩個字段就構成了它的主鍵。值得注意的是，我們通常用一個數字類型的自增的id來作為主鍵，但它不是必須的。
第三范式的要求就更加苛刻了，它要求表中不要有冗余數據，那它的規范就是說：任何非主鍵的屬性都必須依賴於主鍵，但是不能傳遞依賴於主鍵。舉個超經典的例子，這也是我在學習第三范式的時候的例子，因為它太經典了，我可能一輩子都忘記不了。比如說我建立了一個表，它的字段信息如下：（學號，學生姓名，學生所在系名，學生所在系的地址）,猛一看這個表也沒什麼問題，但是它會產生冗余信息，那就是學生所在系的地址這一個屬性也是由學號唯一確定的，但是它不是直接依賴的，它是傳遞依賴的，它直接依賴與系名，而不是學生的學號，因此，我們會發現，對於不同的學號，會導致存儲很多一樣的系名，這就是所謂的冗余信息。
那麼我們怎麼修改呢，答案就是分表，注意，我們還必須遵循第二范式，我們可以增加一個系的編號這麼一個字段，即第一個表信息（學號，學生姓名，所在系編號），第二個表（系編號，系名，系的地址），這麼一來，我們就不會存儲冗余信息了，這就是第三范式所帶來的效果。
除了第三范式之外，還有一個也很重要，叫做BC范式，也就是著名的巴斯-科德范式，它的要求是什麼呢？它是對主鍵的要求，也就是主碼，它要求，主碼的任何一個真自己都不能唯一的確定這個主碼，什麼意思。比如說我把學生的身份證號和學號這兩個合起來 設計為主鍵，它並不違反第三范式，但是它違反了BC范式，原因何在呢？因為在一個學校裡，任何兩個學生的身份證號和學號都不相同，也就是說，我們使用學號作為主鍵或者身份證號作為主鍵都可以，但是使用這兩個一起作為主鍵，沒必要。
我不知道讀者是否暈了，大體思路就是這樣，其實這些范式都是人做出來的，也不難理解，我這裡並沒有引入太多的邏輯符合和專業術語，算是用比較平常的語言來敘述，也是希望更好理解，如果您有什麼問題，可以在下面留言給我。
