數據庫優化查詢的方法以及大訪問量到數據庫時的優化
一.數據庫優化查詢的方法
1.使用索引：
應盡量避免全表掃描，首先考慮在where 以及 order by ,group by 涉及的列上建立索引
2.優化SQL語句：
1>通過explain(查詢優化神器)用來查看SQL語句的執行效果，可以幫助選擇更好的索引和優化查詢語句，寫出更好的優化語句。通常我們可以對比較復雜的尤其是涉及到多表的SELECT語句，把關鍵字explain加到前面，查看執行計劃，例如：
explain select * from news;
2>任何地方都不要使用select * from ，用具體的字段列表代替“*”，不要返回用不到的任何字段。
3>不在索引列做運算或者使用函數。
4>查詢盡可能使用limit 減少返回的行數，減少數據傳輸時間和帶寬浪費。
3.優化數據庫對象
1>.優化表的數據庫類型
使用procedure analyse()函數對表進行分析，該函數可以對表中列的數據類型提出優化建議。能小就用小。表數據類型第一個原則是：使用能正確的表示和儲存數據的最短類型。這樣可以減少對磁盤空間，內存，cpu緩存的使用。
使用方法：select * from 表名 procedure analyse();
2>.對表進行拆分
第一種：垂直拆分
把主鍵和一些列放在一個表中，然後把主鍵和另外的列放到另一個表中。如果一個表中某些列常用，而另外一些列不常用，則可以用垂直拆分。
第二種：水平拆分
根據一列或者多列數據的值把數據行放到第二個獨立的表中
3>.使用中間表來提高查詢速度
創建中間表，表結構和原表結構完全相同，轉移要統計的數據到中間表，然後在中間表上進行統計，得出想要的結果。
4.硬件優化：
1>CUP的優化
選擇多核和主頻高的CPU。
2>內存的優化
使用更大的內存。將盡量多的內存分配給MySQl做緩存
3>磁盤I/O的優化
RAID沒有數據冗余，沒有數據校驗的磁盤陳列。實現RAID0至少需要兩塊以上的磁盤，它將兩塊以上的硬盤合並成一塊，數據連續地分割在每一塊盤上。
RAID1是將一個兩塊硬盤所構成RAID磁盤陣列，其容量僅等於一塊硬盤的容量，因為另一塊只是當作數據“鏡像”。
使用RAID-0+1磁盤陣列，RAID 0+1 是RAID0 和RAID 1的組合形式。它在提供與RAID 1一樣的數據安全保障時，也提供了與RAID 0近似的儲存性能。
4>調整磁盤調度算法
選擇合適的磁盤調度算法，可以減少磁盤的尋道時間。
5.MySQl自身的優化
對MySQl自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。如指定MySQL查詢緩沖區的大小，指定MySQl允許的最大連接進程數等。
6.應用優化
1>使用數據庫連接池
2>使用查詢緩存
它的作用是存儲select查詢的文本及其相應結果。如果隨後收到一個相同的查詢，服務器會從查詢緩存中直接查詢結果。查詢緩存適用於的對象是更新不頻繁的表，當表中數據更改後，查詢緩存中相關條目就會被清空。
二.如果有一個特別大的訪問量到數據庫上，如何優化？
1.使用優化查詢的方法（如上面）
2.主從復制，讀寫分離，負載均衡
目前，大部分主流關系型數據庫都提供了主從復制的功能，通過配置兩臺（或者多臺）數據庫的主從關系，可以將一臺數據庫服務器的數據跟新到另一臺服務器上。網站可以利用數據庫的這一功能，實現數據庫的讀寫分離，從而改善數據庫的負載壓力。一個系統的讀操作遠遠多於寫操作，因此寫操作發向master（主庫），讀操作發向於slaves（從庫）進行操作（簡單的輪詢算法來決定使用哪個slave）。
利用數據庫的讀寫分離，Web服務器在寫數據的時候，訪問主數據庫（master），主數據庫通過主從復制機制將數據更新同步到從數據庫（slave），這樣當Web服務器讀數據的時候，就可以通過從數據庫獲取到數據。這一方案使得在大量讀操作的Web應用可以輕松的讀取數據，二主數據庫也只會承受少量的寫入操作，還可以實現數據的熱備份，可謂是一舉兩得的方案。
1>主從復制原理：
1，影響MySQL-A數據庫的操作，在數據庫執行後，都會寫入本地的日誌系統A中。假設,實時的將變化了的日誌系統中的數據庫事件操作，通過網絡發給MYSQL-B。
MYSQL-B收到後，寫入本地日誌系統B ,然後一條條的將數據庫事件在數據庫中完成。那麽，MYSQL A的變化, MYSQL-B也會變化，這樣就是所謂的MYSQL的復制。
在上面的模型中, MYSQL-A就是主服務器,即master , MYSQL-B就是從服務器,即slave。
日誌系統A ，其實它是MYSQL的日誌類型中的二進制日誌,也就是專用來保存修改數據庫表的所有動作，即bin log。 [註意 MYSQL會在執行語句之後，釋放鎖之前，寫入二進制日誌，確保事務安全]
日誌系統B，並不是二進制日誌，由於它是從MYSQL-A的二進制日誌復制過來的，並不是自己的數據庫變化產生的，有點接力的感覺,稱為中繼日誌,即relay log。
可以發現，通過上面的機制，可以保證MYSQL-A和MYSQL-B的數據庫數據一致，但是時間上肯定有延遲,即MYSQL-B的數據是滯後的。
2，簡化版:
mysql主(稱master)從(稱slave)復制的原理:
(1).master將數據改變記錄到二進制8誌(binary log)中，也即是配置文件log-bin指定的文件(這些記錄叫做二進制日誌事件，binary log events)
PS:從圖中可以看出，Slave服務器中有一個l/O線程(I/O Thread)在不停地監聽Master的二進制日誌(Binary Log)是否有更新；如果沒有它會睡眠等待Master產生新的日誌事件；如果有新的日誌事件(Log Events)；則會將其拷貝至Slave服務器中的中繼日誌(RelayLoal）。
(2).slave將master的二進制日誌事件(binary log events)拷貝到它的中繼日誌(relay log)。
(3).slave重做中繼日誌中的事件，將Master上的改變反映到它自己的數據庫中。所以兩端的數據是完全-樣的。
PS：從圖中可以看出，Slave 服務器中有一個SQL線程(SQL Thread)從中維日誌讀取事件，並重做其中的事件，從而更新Slave的數據，使其與Master中的數據致。只要該線程與10線程保持一致， 中繼日誌通常會位於OS的緩存中，所以中繼日誌的開銷很小，附簡要原理圖：
2>主從復制的幾種方式：
1.同步復制
主服務器在將更新的數據寫入它的二進制日誌（Bin log）文件中後，必須等待驗證所有的從服務器的更新數據是否已經復制到其中，之後才可以自由處理其他進入的事務處理請求。
2.異步復制
主服務器在將更新的數據寫入它的二進制日誌（Bin log）文件中後，無需等待驗證更新數據是否已經復制到從服務器中，就可以自由處理其他進入的事務處理請求。
3.半同步復制
主服務器在將更新的數據寫入它的二進制日誌文件中後，只需要等待驗證其中一臺服務器的更新數據是否已經復制到其中，就可以自由處理其他進入的事務處理請求，其他從服務器不用管。
3.數據庫分表，分區，分庫
1>分表見上面描述
2>分區：
就是把一張表的數據分成多個區塊，這些區塊可以在一個磁盤上，也可以在不同的磁盤上，分區後，表面上還是一張表，但數據散列在多個位置，這樣一來，多塊硬盤同時處理不同的請求，從而提高磁盤I/O讀寫性能，實現比較簡單，包括水平分區和垂直分區。
3>分庫是根據業務不同把相關的表切分到不同的數據庫中，比如web ,bbs ,blog等庫。
數據庫優化查詢的方法以及大訪問量到數據庫時的優化