轉自Tom-shushu原文 數據庫優化查詢的方法以及大訪問量到數據庫時的優化html
1、數據庫優化查詢的方法
1.1使用索引
應儘可能避免全表掃描，首先考慮在where 以及 order by ,group by 涉及的列上創建索引mysql
1.2優化SQL語句
1>經過explain(查詢優化神器)用來查看SQL語句的執行效果，能夠幫助選擇更好的索引和優化查詢語句，寫出更好的優化語句。一般咱們能夠對比較複雜的尤爲是涉及到多表的SELECT語句，把關鍵字explain加到前面，查看執行計劃，例如：web
explain select * from news;
2>任何地方都不要使用select * from ，用具體的字段列表代替「*」，不要返回用不到的任何字段。算法
3>不在索引列作運算或者使用函數。sql
4>查詢儘量使用limit 減小返回的行數，減小數據傳輸時間和帶寬浪費。數據庫
1.3 優化數據庫對象
1>.優化表的數據庫類型緩存
使用procedure analyse()函數對錶進行分析，該函數能夠對錶中列的數據類型提出優化建議。能小就用小。表數據類型第一個原則是：使用能正確的表示和儲存數據的最短類型。這樣能夠減小對磁盤空間，內存，cpu緩存的使用。安全
使用方法：select * from 表名 procedure analyse();服務器
2>.對錶進行拆分網絡
第一種：垂直拆分
把主鍵和一些列放在一個表中，而後把主鍵和另外的列放到另外一個表中。若是一個表中某些列經常使用，而另一些列不經常使用，則能夠用垂直拆分。
第二種：水平拆分
根據一列或者多列數據的值把數據行放到第二個獨立的表中
3>.使用中間表來提升查詢速度
建立中間表，表結構和原表結構徹底相同，轉移要統計的數據到中間表，而後在中間表上進行統計，得出想要的結果。
1.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>調整磁盤調度算法
選擇合適的磁盤調度算法，能夠減小磁盤的尋道時間。
1.5 MySQl自身的優化
對MySQl自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。如指定MySQL查詢緩衝區的大小，指定MySQl容許的最大鏈接進程數等。
1.6 應用優化
1>使用數據庫鏈接池
2>使用查詢緩存
它的做用是存儲select查詢的文本及其相應結果。若是隨後收到一個相同的查詢，服務器會從查詢緩存中直接查詢結果。查詢緩存適用於的對象是更新不頻繁的表，當表中數據更改後，查詢緩存中相關條目就會被清空。
2、若是有一個特別大的訪問量到數據庫上，如何優化？
2.1 使用優化查詢的方法（如上面）
2.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.半同步複製
主服務器在將更新的數據寫入它的二進制日誌文件中後，只須要等待驗證其中一臺服務器的更新數據是否已經複製到其中，就能夠自由處理其餘進入的事務處理請求，其餘從服務器不用管。
2.3 數據庫分表，分區，分庫
1>分表見上面描述
2>分區：
就是把一張表的數據分紅多個區塊，這些區塊能夠在一個磁盤上，也能夠在不一樣的磁盤上，分區後，表面上仍是一張表，但數據散列在多個位置，這樣一來，多塊硬盤同時處理不一樣的請求，從而提升磁盤I/O讀寫性能，實現比較簡單，包括水平分區和垂直分區。
3>分庫是根據業務不一樣把相關的表切分到不一樣的數據庫中，好比web ,bbs ,blog等庫。