首先是如何檢查SQL的效率. 1.善用explain: 設計SQL后，應使用explain命令檢查SQL，看是否使用到索引，是否存在filesort,重點檢查檢索的行數(shù)（rows）是否太大。 一般來說. rows1000，是在可接受的范圍內(nèi)的。 rows在1000~1w之間，在密集訪問時可能導致性能問題

首先是如何檢查SQL的效率.

1.善用explain:

設計SQL后，應使用explain命令檢查SQL，看是否使用到索引，是否存在filesort,重點檢查檢索的行數(shù)（rows）是否太大。

一般來說.

rows<1000，是在可接受的范圍內(nèi)的。

rows在1000~1w之間，在密集訪問時可能導致性能問題，但如果不是太頻繁的訪問（頻率低于1分鐘一次），又難再優(yōu)化的話，可以接受，但需要注意觀察

rows大于1萬時，應慎重考慮SQL的設計，優(yōu)化SQL，優(yōu)化db，一般來說不允許頻繁運行（頻率低于1小時一次）。

rows達到10w級別時，堅決不能做為實時運行的SQL。但導數(shù)據(jù)場合除外，但導數(shù)據(jù)必須控制好時間，頻度。

explain SQL語句應該是日常開發(fā)中的習慣動作，有時explain出來的結果，可能會出于偏離設計的意料之外,所以

**強烈建議在設計SQL，尤其是稍微復雜的SQL時，一定要在測試環(huán)境甚至是實際環(huán)境上預先進行explain**

2.MySQL慢查詢?nèi)罩?/p>

一般應打開MySQL的慢查詢?nèi)罩?在my.cnf中加入log_slow_queries和long_query_time兩個參數(shù)),會記錄所有查詢持續(xù)時間超過long_query_time的SQL語句，把這些語句log下來之后，再一一分析(explain)優(yōu)化。

3.監(jiān)視當前進程

登陸MySQL,使用show processlist查看正在運行的SQL語句，如果正在運行的語句太多，運行時間太長，表示MySQL效率有問題。必要的時候可以將對應的進程kill掉。

4.系統(tǒng)命令

使用top/vmstat等系統(tǒng)命令來檢查MySQL進程占用的cpu,內(nèi)存,以及磁盤IO量。

對MySQL優(yōu)化的文章很多，這里只提幾點平時工作中比較常用到的方法。

◆建表時,顯式指定使用innodb數(shù)據(jù)庫引擎，而不是myisam,myisam引擎的鎖是表鎖,讀鎖和寫鎖是互斥的，讀寫操作是串行的，鎖沖突會嚴重影響并發(fā).而innodb提供行級鎖，能提供較好的并發(fā)表現(xiàn)，在我們的業(yè)務場景里，也不會引起死鎖。

◆善用索引，對SQL語句where條件里使用到的字段，合理建立索引。雖然對表建立索引一定程度上會影響寫入效率，但在表數(shù)據(jù)規(guī)模不大，寫入壓力不是特別高的情況下，索引帶來的好處是更多的。

◆當SQL語句是由代碼動態(tài)生成的，如在運行時根據(jù)用戶操作加入不同的where參數(shù)，應在測試階段對SQL生成的典型情況和邊界情況進行測試，看是否有可能造成性能問題。并應適當生成一些日志，供提取最終生成的SQL進行效率分析。

◆對數(shù)據(jù)應合理分庫分表，由應用層去動態(tài)的選擇庫和表。MySQL的innodb表雖然理論上可以裝海量的數(shù)據(jù)，但在我們的業(yè)務場景下，數(shù)據(jù)控制在500w以下會比較合理，追求性能的話，最好控制在200w以下，合理索引。

◆需要聯(lián)合查詢時善用left join/right join而不是直接多表聯(lián)合，怎么用，查manul ^_^

◆盡量不要使用select套select的復合查詢，如果能拆開，盡量拆開,多條精悍的SQL,組合起來可能就是一條龐大的SQL，應該避免。

◆善用cache,將不常修改的，數(shù)據(jù)量有限的,又是被密集查詢的信息，加載到cache里，可以有效的降低數(shù)據(jù)庫壓力。在一般的業(yè)務場景里，推薦使用開源memcache，簡單高效。

◆如果一些邏輯可以放到應用層去完成，可以考慮放到應用層去完成。但如果將SQL邏輯分拆到應用層可能導致對數(shù)據(jù)更頻繁的訪問的話，那么需要考慮修改應用邏輯，數(shù)據(jù)結構，或回到合理的聯(lián)合查詢上來。

比如某些數(shù)據(jù)的排序可以load到php數(shù)組里，再sort.又比如需要查詢A,B兩個表，A表里的數(shù)據(jù)是B表里某個字段的對照說明（如A:t_service表，B.t_task表），A表數(shù)據(jù)量有限，可以做聯(lián)合查詢，也可以先將A表先load到進程或內(nèi)存里，用hash結構cache起來，再查B表，然后在cache里依次查詢hash，獲得對照說明。

◆關于導數(shù)據(jù)和統(tǒng)計性查詢.導數(shù)據(jù)在計算和磁盤io上對數(shù)據(jù)庫壓力都會很大，應在時間和空間上合理分攤數(shù)據(jù)庫壓力如果需要導出批量的特定數(shù)據(jù)做分析，應建立專供數(shù)據(jù)分析的數(shù)據(jù)庫服務器，或者建立臨時庫表，先導出數(shù)據(jù)，再在上面做分析運算。

導數(shù)據(jù)等可能引起批量數(shù)據(jù)讀取的操作，應建立定時任務，在數(shù)據(jù)庫不繁忙的時段（凌晨1~7時)運行一般的統(tǒng)計操作，對實時性要求都不會太高（5~10分鐘以上，甚至一天，一周等），這種數(shù)據(jù)不應在每次訪問時運行庫中直接count,group,而是應該由定時任務導出，建立結果表或中間結果表，供最終用戶使用。

◆生產(chǎn)數(shù)據(jù)庫上的操作權限應嚴格控制，而開發(fā)人員在生產(chǎn)數(shù)據(jù)庫上直接運行SQL語句，要盡量慎重。

能做到以上這些，基本上可以算MySQL以及相關系統(tǒng)優(yōu)化入門，可以保證不要讓我們的數(shù)據(jù)庫整天累趴下了。

最后，即使做足了功課，也還是要例行的對數(shù)據(jù)庫運行情況進行觀察，監(jiān)控，盡早發(fā)現(xiàn)其性能瓶頸，在未造成危害前解決掉。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com