最近開始研究資料庫方面的東西，感覺能解決大資料的問題，感覺真的很爽，所以，可以學習了一下
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等待的時間就少了，自然速度就是上去了
資料庫訪問層
using system using system.data.sqlclient namespace dbcontrol setpublic sqlconnection sqlconnectionstring public string xmlconnectionstring set public ...
MySQL資料庫（一） 資料庫基礎
資料庫介紹 db database 資料庫 dbms database management system 資料庫管理系統 dba 資料庫管理員 database administrator 資料 描述事物的符號記錄稱為記錄 數字 文字 影象 聲音 表 不同的組織記錄在一起形成表 資料庫 資料的集合...
Zen Cart 資料庫抽象層
下面的查詢語句用來檢索給定商品的型號 view plain theproductid 25 global db sql select products model from table products where products id productid sql db bindvars sql ...