mysql最佳化SQL語句消耗

來源:互聯網
上載者:User

標籤:mysql   設定檔   

  1. 開啟SQL的慢日誌查詢

設定檔檔案中填寫如下配置並重啟mysql

log_queries_not_using_indexes

#這個參數設定為ON,可以捕獲到所有未使用索引的SQL語句,儘管這個SQL語句有可能執行得挺快。

log-bin=mysql-bin  slow_query_log=on    long_query_time=2    log_queries_not_using_indexes=on  slow-query-log-file=/var/lib/mysql/slowquery.log
 show variables like "%slow_query%";+---------------------+------------------------------+| Variable_name       | Value                        |+---------------------+------------------------------+| slow_query_log      | ON                           || slow_query_log_file | /var/lib/mysql/slowquery.log |+---------------------+------------------------------+2 rows in set (0.00 sec)
show variables like "%long_query_time%";+-----------------+----------+| Variable_name   | Value    |+-----------------+----------+| long_query_time | 2.000000 |+-----------------+----------+1 row in set (0.00 sec)

注意開啟 slow query log 會對效能有一定的影響.

分析慢日誌

mysqldumpslow -s c -t 20 /var/lib/mysql/slowquery.log

其中:

-s, 是表示按照何種方式排序,c、t、l、r分別是按照記錄次數、時間、查詢時間、返回的記錄數來排序,ac、at、al、ar,表示相應的倒敘;

-t, 是top n的意思,即為返回前面多少條的資料;

-g, 後邊可以寫一個正則匹配模式,大小寫不敏感的;

例如:

mysqldumpslow -s r -t 10 /var/lib/mysql/slowquery.log                               

得到返回記錄集最多的10個查詢。

mysqldumpslow -s t -t 10 -g “left join” /var/lib/mysql/slowquery.log    

得到按照時間排序的前10條裡面含有左串連的查詢語句。

使用mysqldumpslow命令可以非常明確的得到各種我們需要的查詢語句,對MySQL查詢語句的監控、分析、最佳化是MySQL最佳化非常重要的一步。開啟慢查詢日誌後,由於日誌記錄操作,在一定程度上會佔用CPU資源影響mysql的效能,但是可以階段性開啟來定位效能瓶頸。




2.短時間分析慢的查詢(此方法比較耗時)

show variables like "%pro%";+---------------------------+-------+| Variable_name             | Value |+---------------------------+-------+| have_profiling            | YES   || profiling                 | OFF   || profiling_history_size    | 15    || protocol_version          | 10    || proxy_user                |       || slave_compressed_protocol | OFF   || stored_program_cache      | 256   |+---------------------------+-------+7 rows in set (0.00 sec)


a.開啟分析

mysql> set profiling=1;  #-- 開啟分析

開啟後information_schema 的 database 會建立一個PROFILING 的 table 記錄. 

b.運行要分析的sql語句

c.分析剛剛執行的sql語句

show profiles; #-- 顯示最近所有語句的分析,預設最大數量為15,可設最大數量為100show profile for query 1; #-- 查看剛執行的第N條語句中,具體的時間消耗show profile cpu,memory for query 1;show profile cpu,block io,memory,swaps,context switches,source for query 1;

d.關閉分析 

set profiling=0; #-- 關閉分析


4.show processlist 命令

 show processlist;+-----+----------+----------------------+--------------------+---------+-------+-------+------------------+| Id  | User     | Host                 | db                 | Command | Time  | State | Info             |+-----+----------+----------------------+--------------------+---------+-------+-------+------------------+| 861 | warmdata | ip:51724 | collect            | Sleep   | 15920 |       | NULL             || 880 | root     | localhost            | information_schema | Query   |     0 | NULL  | show processlist || 881 | warmdata | ip:18730 | information_schema | Sleep   |  1542 |       | NULL             || 882 | warmdata | ip:18732 | NULL               | Sleep   | 12312 |       | NULL             |+-----+----------+----------------------+--------------------+---------+-------+-------+------------------+

SHOW PROCESSLIST顯示哪些線程正在運行。您也可以使用mysqladmin processlist語句得到此資訊。

各列的含義和用途:

ID列

一個標識,你要kill一個語句的時候很有用,用命令殺掉此查詢 /*/mysqladmin kill 進程號。

user列

顯示單前使用者,如果不是root,這個命令就只顯示你許可權範圍內的sql語句。

host列

顯示這個語句是從哪個ip的哪個連接埠上發出的。用於追蹤出問題語句的使用者。

db列

顯示這個進程目前串連的是哪個資料庫。

command列

顯示當前串連的執行的命令,一般就是休眠(sleep),查詢(query),串連(connect)。

time列

此這個狀態持續的時間,單位是秒。

state列

顯示使用當前串連的sql語句的狀態,很重要的列,後續會有所有的狀態的描述,請注意,state只是語句執行中的某一個狀態,一個 sql語句,以查詢為例,可能需要經過copying to tmp table,Sorting result,Sending data等狀態才可以完成

info列

顯示這個sql語句,因為長度有限,所以長的sql語句就顯示不全,但是一個判斷問題語句的重要依據。


這個命令中最關鍵的就是state列,mysql列出的狀態主要有以下幾種:

Checking table

 正在檢查資料表(這是自動的)。

Closing tables

 正在將表中修改的資料重新整理到磁碟中,同時正在關閉已經用完的表。這是一個很快的操作,如果不是這樣的話,就應該確認磁碟空間是否已經滿了或者磁碟是否正處於重負中。

Connect Out

 複製從伺服器正在串連主伺服器。

Copying to tmp table on disk

 由於臨時結果集大於tmp_table_size,正在將暫存資料表從記憶體儲存轉為磁碟儲存以此節省記憶體。

Creating tmp table

 正在建立暫存資料表以存放部分查詢結果。

deleting from main table

 伺服器正在執行多表刪除中的第一部分,剛刪除第一個表。

deleting from reference tables

 伺服器正在執行多表刪除中的第二部分,正在刪除其他表的記錄。

Flushing tables

 正在執行FLUSH TABLES,等待其他線程關閉資料表。

Killed

 發送了一個kill請求給某線程,那麼這個線程將會檢查kill標誌位,同時會放棄下一個kill請求。MySQL會在每次的主迴圈中檢查kill標誌位,不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了,那麼kill請求會在鎖釋放時馬上生效。

Locked

 被其他查詢鎖住了。

Sending data

 正在處理SELECT查詢的記錄,同時正在把結果發送給用戶端。

Sorting for group

 正在為GROUP BY做排序。

 Sorting for order

 正在為ORDER BY做排序。

Opening tables

 這個過程應該會很快,除非受到其他因素的幹擾。例如,在執ALTER TABLE或LOCK TABLE語句行完以前,資料表無法被其他線程開啟。正嘗試開啟一個表。

Removing duplicates

 正在執行一個SELECT DISTINCT方式的查詢,但是MySQL無法在前一個階段最佳化掉那些重複的記錄。因此,MySQL需要再次去掉重複的記錄,然後再把結果發送給用戶端。

Reopen table

 獲得了對一個表的鎖,但是必須在表結構修改之後才能獲得這個鎖。已經釋放鎖,關閉資料表,正嘗試重新開啟資料表。

Repair by sorting

 修複指令正在排序以建立索引。

Repair with keycache

 修複指令正在利用索引緩衝一個一個地建立新索引。它會比Repair by sorting慢些。

Searching rows for update

 正在講合格記錄找出來以備更新。它必須在UPDATE要修改相關的記錄之前就完成了。

Sleeping

 正在等待用戶端發送新請求.

System lock

 正在等待取得一個外部的系統鎖。如果當前沒有運行多個mysqld伺服器同時請求同一個表,那麼可以通過增加--skip-external-locking參數來禁止外部系統鎖。

Upgrading lock

 INSERT DELAYED正在嘗試取得一個鎖表以插入新記錄。

Updating

 正在搜尋匹配的記錄,並且修改它們。

User Lock

 正在等待GET_LOCK()。

Waiting for tables

 該線程得到通知,資料表結構已經被修改了,需要重新開啟資料表以取得新的結構。然後,為了能的重新開啟資料表,必須等到所有其他線程關閉這個表。以下幾種情況下會產生這個通知:FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。

waiting for handler insert

 INSERT DELAYED已經處理完了所有待處理的插入操作,正在等待新的請求。

 大部分狀態對應很快的操作,只要有一個線程保持同一個狀態好幾秒鐘,那麼可能是有問題發生了,需要檢查一下。

 還有其他的狀態沒在上面中列出來,不過它們大部分只是在查看伺服器是否有存在錯誤是才用得著。


5.使用explain


explain select * from c_task_detail_assist;+----+-------------+----------------------+------+---------------+------+---------+------+------+-------+| id | select_type | table                | type | possible_keys | key  | key_len | ref  | rows | Extra |+----+-------------+----------------------+------+---------------+------+---------+------+------+-------+|  1 | SIMPLE      | c_task_detail_assist | ALL  | NULL          | NULL | NULL    | NULL | 3220 |       |+----+-------------+----------------------+------+---------------+------+---------+------+------+-------+1 row in set (0.00 sec)

EXPLAIN列的解釋

table

顯示這一行的資料是關於哪張表的

type

這是重要的列,顯示串連使用了何種類型。從最好到最差的連線類型為const、eq_reg、ref、range、indexhe和ALL

possible_keys

顯示可能應用在這張表中的索引。如果為空白,沒有可能的索引。可以為相關的域從WHERE語句中選擇一個合適的語句

key

實際使用的索引。如果為NULL,則沒有使用索引。很少的情況下,MYSQL會選擇最佳化不足的索引。這種情況下,可以在SELECT語句 中使用USE INDEX(indexname)來強制使用一個索引或者用IGNORE INDEX(indexname)來強制MYSQL忽略索引

key_len

使用的索引的長度。在不損失精確性的情況下,長度越短越好

ref

顯示索引的哪一列被使用了,如果可能的話,是一個常數

rows

MYSQL認為必須檢查的用來返回請求資料的行數

Extra

關於MYSQL如何解析查詢的額外資訊。將在表4.3中討論,但這裡可以看到的壞的例子是Using temporary和Using filesort,意思MYSQL根本不能使用索引,結果是檢索會很慢


extra列返回的描述的意義

Distinct

一旦MYSQL找到了與行相聯合匹配的行,就不再搜尋了

Not exists

MYSQL最佳化了LEFT JOIN,一旦它找到了匹配LEFT JOIN標準的行,就不再搜尋了

Range checked for each Record(index map:#)

沒有找到理想的索引,因此對於從前面表中來的每一個行組合,MYSQL檢查使用哪個索引,並用它來從表中返回行。這是使用索引的最慢的串連之一

Using filesort

看到這個的時候,查詢就需要最佳化了。MYSQL需要進行額外的步驟來發現如何對返回的行排序。它根據連線類型以及儲存排序索引值和匹配條件的全部行的行指標來排序全部行

Using index

列資料是從僅僅使用了索引中的資訊而沒有讀取實際的行動的表返回的,這發生在對錶的全部的請求列都是同一個索引的部分的時候

Using temporary

看到這個的時候,查詢需要最佳化了。這裡,MYSQL需要建立一個暫存資料表來儲存結果,這通常發生在對不同的列集進行ORDER BY上,而不是GROUP BY上

Where used

使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給使用者。如果不想返回表中的全部行,並且連線類型ALL或index,這就會發生,或者是查詢有問題不同連線類型的解釋(按照效率高低的順序排序)

const

表中的一個記錄的最大值能夠匹配這個查詢(索引可以是主鍵或惟一索引)。因為只有一行,這個值實際就是常數,因為MYSQL先讀這個值然後把它當做常數來對待

eq_ref

在串連中,MYSQL在查詢時,從前面的表中,對每一個記錄的聯合都從表中讀取一個記錄,它在查詢使用了索引為主鍵或惟一鍵的全部時使用

ref

這個連線類型只有在查詢使用了不是惟一或主鍵的鍵或者是這些類型的部分(比如,利用最左邊首碼)時發生。對於之前的表的每一個行聯合,全部記錄都將從表中讀出。這個類型嚴重依賴於根據索引匹配的記錄多少—越少越好

range

這個連線類型使用索引返回一個範圍中的行,比如使用>或<尋找東西時發生的情況

index

這個連線類型對前面的表中的每一個記錄聯合進行完全掃描(比ALL更好,因為索引一般小於表資料)

ALL

這個連線類型對於前面的每一個記錄聯合進行完全掃描,這一般比較糟糕,應該盡量避免


參考連結:http://blog.sina.com.cn/s/blog_ad0672d60102vag4.html

http://zhidao.baidu.com/link?url=209y3CUJ84_KZPk5pLELNu5RxbuszmPTD81Gi8Z-pa7Hq61aUy4PR-HT3EtOATp5KiX0vG8IVBIhCfd1cUyh-8jo9BOJ3fLcoMqVeFQuRS7

http://blog.csdn.net/lxpbs8851/article/details/7834836(推薦)

mysql最佳化SQL語句消耗

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.