最近開始研究數據庫方面的東西，感覺能解決大數據的問題，感覺真的很爽，所以，可以學習了一下
sql方面的優化，這個將是一系列的課程，學習的過程中，將其記錄下來，以後以備備案，同樣，技術
是一個沒有邊界的東西，寫出來代表我的個人理解，真心希望大神們來此圍觀一下，提提意見，感激不
盡
一、數據庫優化概覽
高性能的數據庫依賴與幾個因素，如表結構，查詢語句，服務器的硬件配置和軟件的設置。軟件上
的構造直接導致了硬件層CPU和I/O操作，所以，我們優化的策略，一般爲，減少不必要的磁盤I/O，儘量
利用好表的物理結構如索引來快速訪問數據，達到高效的查詢。
1.1、在數據庫層的優化
讓數據庫應用更加快速的最重要的因素當然是他的基本的 設計，如：
1,表的結構是否合理，這些表現在：是否使用了正確的數據類型，如果是一個寫頻繁的結構，是否一次
一次寫入，會更新到很多的列，這些的負荷是，會有相應的索引需要進行維護
2,是否使用了正確的索引，這個很重要，如果使用不當，當數據很大的時候，可能會被全部掃描，這樣
如果內存不夠大，會利用相應的磁盤進行排序等操作，將會非常慢
3,是否使用了合理的存儲引擎，當然我現在使用的mysql，對於innodb來說，效果還是不錯了，當然，
如果你的引用對於事物要求不是很高，可以考慮要嗯MyISM,這個存儲引擎的速度真心比較快的，但
就是安全性方面有待考慮
4,是否使用了正確的行格式，mysql中支出壓縮的行格式，這樣會導致更少的磁盤I/O和讀寫數據，當然
他的不好的地方是不能在此上建立好的索引和進行數據的比較
5,是否你的應用程序使用了了鎖策略，對於Innodb，使用了行級鎖，這鼓勵更多的並行操作，如果對與
應用程序，如果能把鎖移動到應用程序中，使用相應的語言特性，或是系統調用如互斥鎖，信號量等
來處理，而不應該把維護數據的正確行來鎖表
6,是否使用了合理的緩存cache,這個緩存就更內存的分頁一樣，大了的話，會造成大量的碎片不能使用，
因此，很多查詢沒有地方緩存而清空之前的緩存，當下一次查詢時，就不能利用緩存了，另外，如果
小了，會造成mysql對緩存的管理壓力加大，因爲會爲沒一次查詢可能分好幾頁來緩存數據，管理這些
數據是需要一定的開銷的
1.2、硬件層的優化
當數據庫更加忙的時候，對硬件的要求就更高了，因此，我們應該更快，更好的識別出系統的瓶頸，早
些做決定，是否更換或添加相應的硬件，典型的瓶頸出現在這麼幾個地方：
1,磁盤尋道和讀寫
磁盤的尋道速度直接決定了訪問數據的快慢，而磁盤磁頭的尋道速度是有限的，因此，可以考慮
讓數據並行讀取，比如放在多個磁盤裏讀，這個還沒有測試，原理上我覺得可行，因爲對與單磁盤
其實他是實現的並行讀寫的，因爲磁盤的主軸帶動磁頭旋轉，那麼一次就可以讀取一個柱面，而
大多數的服務器都是多個磁盤，可以考慮配置數據庫支持多盤存放，並行讀寫，這個將更加快速。
2,內存帶寬
當CPU需要更多的數據來填充cache時，主存可能會變成一個瓶頸，可以考慮更快更大的內存，
相比，更快可能會好些，因爲cpu的處理速度比內存的速度高几個數量級，如果內存足夠快，相對
來說，CPU等待的時間就少了，自然速度就是上去了