1. 程式人生 > >MySQL影響性能的因素原因以及性能優化配置詳解

MySQL影響性能的因素原因以及性能優化配置詳解

產出 詳細 告訴 rbo 如果 進制 valid 操作符 最優

(https://blog.csdn.net/kangshuo2471781030/article/details/79315577)

一、MySQL性能優化之-影響性能的因素

1.商業需求的影響

不合理需求造成資源投入產出比過低,這裏我們就用一個看上去很簡單的功能來分析一下。

需求:一個論壇帖子總量的統計,附加要求:實時更新

從功能上來看非常容易實現,執行一條SELECT COUNT(*) from 表名的Query 就可以得到結果。但是,如果我們采用不是MyISAM 存儲引擎,而是使用的Innodb 的存儲引擎,那麽大家可以試想一下,如果存放帖子的表中已經有上千萬的帖子的時候,執行這條Query 語句需要多少成本?恐怕再好的硬件設備,都不可能在10秒之內完成一次查詢吧

註:沒有where的count(*)使用MyISAM要比InnoDB快得多。因為MyISAM內置了一個計數器,count(*)時它直接從計數器中讀,而InnoDB必須掃描全表。所以在InnoDB上執行count(*)時一般要伴隨where,且where中要包含主鍵以外的索引列。

既然這樣查詢不行,那我們是不是該專門為這個功能建一個表,就只有一個字段,一條記錄,就存放這個統計量,每次有新的帖子產生的時候,都將這個值增加1,這樣我們每次都只需要查詢這個表就可以得到結果了,這個效率肯定能夠滿足要求了。確實,查詢效率肯定能夠滿足要求,可是如果帖子產生很快,在高峰時期可能每秒就有幾十甚至上百個帖子新增操作的時候,恐怕這個統計表又要成為大家的噩夢了。要麽因為並發的問題造成統計結果的不準確,要麽因為鎖資源爭用嚴重造成整體性能的大幅度下降。

其實這裏問題的焦點不應該是實現這個功能的技術細節,而是在於這個功能的附加要求“實時更新”上面。當一個論壇的帖子數量很大了之後,到底有多少人會關註這個統計數據是否是實時變化的?有多少人在乎這個數據在短時間內的不精確性?恐怕不會有人會盯著這個統計數字並追究當自己發了一個帖子然後回頭刷新頁面發現這個統計數字沒有加1 吧?所以只要去掉了這個“實時更新”的附加條件,就可以非常容易的實現這個功能了。就像之前所提到的那樣,通過創建一個統計表,然後通過一個定時任務每隔一定時間段去更新一次裏面的統計值,這樣既可以解決統計值查詢的效率問題,又可以保證不影響新發貼的效率,一舉兩得。

2.系統架構及實現的影響

所有數據都是適合在數據庫中存放的嗎?數據庫為我們提供了太多的功能,反而讓很多並不是太了解數據庫的人錯誤的使用了數據庫的很多並不是太擅長或者對性能影響很大的功能,最後卻全部怪罪到數據庫身上。

實際上,以下幾類數據都是不適合在數據庫中存放的:

(1.) 二進制多媒體數據

這種數據主要包括圖片,音頻、視頻和其他一些相關的二進制文件。將二進制多媒體數據存放在數據庫中,一個問題是數據庫空間資源耗用非常嚴重,另一個問題是這些數據的存儲很消耗數據庫主機的CPU 資源。這些數據的處理本不是數據庫的優勢,如果我們硬要將他們塞入數據庫,肯定會造成數據庫的處理資源消耗嚴重。

(2.)超大文本數據

對於5.0.3 之前的MySQL 版本,VARCHAR 類型的數據最長只能存放255 個字節,如果需要存儲更長的文本數據到一個字段,我們就必須使用TEXT 類型(最大可存放64KB)的字段,甚至是更大的LONGTEXT 類型(最大4GB)。而TEXT類型數據的處理性能要遠比VARCHAR 類型數據的處理性能低下很多。從5.0.3 版本開始,VARCHAR 類型的最大長度被調整到64KB 了,所以,超大文本數據存放在數據庫中不僅會帶來性能低下的問題,還會帶來空間占用的浪費問題。

是否合理的利用了應用層Cache 機制?

對於Web 應用,活躍數據的數據量總是不會特別的大,有些活躍數據更是很少變化。對於這類數據,我們是否有必要每次需要的時候都到數據庫中去查詢呢?如果我們能夠將變化相對較少的部分活躍數據通過應用層的Cache 機制Cache 到內存中,對性能的提升肯定是成數量級的,而且由於是活躍數據,對系統整體的性能影響也會很大。

3.查詢語句對性能的影響

SQL語句的優劣是對性能有影響的,每個SQL 語句在優化之前和優化之後的性能差異也是各不相同。

在數據庫管理軟件中,最大的性能瓶頸就是在於磁盤IO,也就是數據的存取操作上面。而對於同一份數據,當我們以不同方式去尋找其中的某一點內容的時候,所需要讀取的數據量可能會有天壤之別,所消耗的資源也自然是區別很大。

功能完全相同的兩條SQL 的在性能方面的差異。

我們在執行sql語句時可以用explain來查看執行計劃:

還可以打開mysql的profiling 功能,來查看sql的實際執行計劃

通過執行“SHOW PROFILE”命令獲取當前系統中保存的多個Query 的profile 的概要信息。;

4.數據庫Schema設計對性能的影響

5.硬件選擇對性能的影響

首先,數據庫主機是存取數據的地方,所以數據庫主機的IO 性能肯定是需要最優先考慮的一個因素,這一點不管是什麽類型的數據庫應用都是適用的。在主機中決定IO 性能部件主要由磁盤和內存所決定,當然也包括各種與IO 相關的板卡。

其次,由於數據庫主機和普通的應用程序服務器相比,資源要相對集中很多,單臺主機上所需要進行的計算量自然也就比較多,所以數據庫主機的CPU處理能力也不能忽視。

最後,由於數據庫負責數據的存儲,與各應用程序的交互中傳遞的數據量比其他各類服務器都要多,所以數據庫主機的網絡設備的性能也可能會成為系統的瓶頸。

所以,數據庫應用系統的優化,實際上是一個需要多方面配合,多方面優化的才能產生根本性改善的事情。簡單來說,可以通過下面三句話來簡單的概括數據庫應用系統的性能優化:商業需求合理化,系統架構最優化,邏輯實現精簡化,硬件設施理性化。

二、MySQL性能優化之-索引

關於MySQL索引的好處,如果正確合理設計並且使用索引的MySQL是一輛蘭博基尼的話,那麽沒有設計和使用索引的MySQL就是一個人力三輪車。對於沒有索引的表,單表查詢可能幾十萬數據就是瓶頸,而通常大型網站單日就可能會產生幾十萬甚至幾百萬的數據,沒有索引查詢會變的非常緩慢。

做一個簡單測試,假如我們創建了一個tb1表,向表中插入20000行數據,表的創建和數據插入用如下腳本實現

[css] view plain copy
  1. [root@mysql ~]# cat mysql.sh
[css] view plain copy
  1. #!/bin/bash
  2. HOSTNAME="localhost"
  3. PORT="3306"
  4. USERNAME="root"
  5. PASSWORD="pwd123"
  6. DBNAME="tables"
  7. TABLENAME="tb1"
  8. #create database
  9. mysql -h ${HOSTNAME} -P ${PORT} -u ${USERNAME} -p${PASSWORD} -e "drop database if exists ${DBNAME}"
  10. create_db_sql="create database if not exists ${DBNAME}"
  11. mysql -h ${HOSTNAME} -P ${PORT} -u ${USERNAME} -p${PASSWORD} -e "${create_db_sql}"
  12. #create table
  13. create_table_sql="create table if not exists ${TABLENAME}(stuid int not null primary key,stuname varchar(20) not null,stusex char(1) not null,cardid varchar(20) not null,birthday datetime,entertime datetime,address varchar(100) default null)"
  14. mysql -h ${HOSTNAME} -P ${PORT} -u ${USERNAME} -p${PASSWORD} ${DBNAME} -e "${create_table_sql}"
  15. #insert data to table
  16. i=1
  17. while [ $i -le 20000 ]
  18. do
  19. insert_sql="insert into ${TABLENAME} values ($i,‘zhangsan‘,‘1‘,‘1234567890123456‘,‘1999-10-10‘,‘2016-9-3‘,‘zhongguo beijingshi changpinqu‘)"
  20. mysql -h ${HOSTNAME} -P ${PORT} -u ${USERNAME} -p${PASSWORD} ${DBNAME} -e "${insert_sql}"
  21. let i++
  22. done
  23. #select data
  24. select_sql="select count(*) from ${TABLENAME}"
  25. mysql -h ${HOSTNAME} -P ${PORT} -u ${USERNAME} -p${PASSWORD} ${DBNAME} -e "${select_sql}"

再手動插入一行數據,如

下面開始測試,查詢stuname=’admin’的記錄

情況1:stuname列上沒有創建索引的情況

情況2:stuname列上創建索引的情況再查詢

[css] view plain copy
  1. mysql> create index index_stuname on tb1(stuname);

在查找stuname="admin"的記錄時,如果在stuname上已經建立了索引,MySQL無須任何掃描全表,即準確可找到該記錄。相反,MySQL會掃描所有記錄。

所以在數據庫表中,對字段建立索引可以大大提高查詢速度。

索引是在存儲引擎中實現的,而不是在服務器層中實現的。所以,每種存儲引擎的索引都不一定完全相同,並不是所有的存儲引擎都支持所有的索引類型。

索引概述:

什麽是索引?

索引(Index)是幫助MySQL高效獲取數據的數據結構,這是一種比較官方的說法。它的存在形式是文件。索引能夠幫助我們快速定位數據。 更通俗的說,數據庫索引好比是一本書前面的目錄,能加快數據庫的查詢速度。

索引的數據結構

這裏主介紹B-tree索引的結構

如上圖,是一顆b+樹,這裏只說一些重點,淺藍色的塊我們稱之為一個磁盤塊,可以看到每個磁盤塊包含幾個數據項(深藍色所示)和指針(黃色所示),如磁盤塊1包含數據項17和35,包含指針P1、P2、P3,P1表示小於17的磁盤塊,P2表示在17和35之間的磁盤塊,P3表示大於35的磁盤塊。真實的數據存在於葉子節點即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非葉子節點只不存儲真實的數據,只存儲指引搜索方向的數據項和指針,如17、35並不真實存在於數據表中。

b+樹的查找過程

如圖所示,如果要查找數據項29,那麽首先會把磁盤塊1由磁盤加載到內存,此時發生一次IO,在內存中用二分查找確定29在17和35之間,鎖定磁盤塊1的P2指針,內存時間因為非常短(相比磁盤的IO)可以忽略不計,通過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存,發生第二次IO,29在26和30之間,鎖定磁盤塊3的P2指針,通過指針加載磁盤塊8到內存,發生第三次IO,同時內存中做二分查找找到29,結束查詢,總計三次IO。真實的情況是,3層的b+樹可以表示上百萬的數據,如果上百萬的數據查找只需要三次IO,性能提高將是巨大的,如果沒有索引,每個數據項都要發生一次IO,那麽總共需要百萬次的IO,顯然成本非常非常高。

為什麽使用索引?

索引可以讓mysql高效運行,可以大大提高mysql的查詢(包括排序,分組)效率;數據約束(唯一索引的建立)。

索引給我帶來什麽好處?

提高查詢效率,快速定位數據

使用索引產生的代價?

1、索引本身是以文件的形式存放在硬盤,需要的時候才加載至內存,所以添加索引會增加磁盤的開銷;

2、寫數據:需要更新索引,對數據庫是個很大的開銷,降低表更新、添加和刪除的速度

不建議使用索引的情況:

(a) 表記錄較少

(b) 索引的選擇性較低,所謂索引的選擇性,是指不重復的索引值與表記錄數的比值,取值範圍(0-1)。選擇性越高,索引的價值越大。

索引的類型?

索引包括單列索引和組合索引

單列索引,即一個索引只包含單個列,一個表可以有多個單列索引,但這不是組合索引。組合索引,即一個索包含多個列。

1、 普通索引

這是最基本的索引,它沒有任何限制

[css] view plain copy
  1. CREATE INDEX indexName ON tablename(column1[,column2,……])

2、 唯一索引

它與前面的普通索引類似,不同的就是索引列的值必須唯一,但允許空值,空值是指null。如果是組合索引,組合列的值必須唯一 。

[css] view plain copy
  1. CREATE UNIQUE INDEX indexName ON tablename(column1[,column2,……])

主鍵索引:一種特殊的唯一索引,不允許有空值,一般在建表的時候同時建立主鍵索引

CREATE TABLE tablename(ID INT NOTNULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) );

3、組合索引

為了進一步提升MySQL的效率,就要考慮建立組合索引

例如:創建一個表,包含如下字段

[css] view plain copy
  1. CREATE TABLE mytable(ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL );

將username, city, age建到一個索引裏

[css] view plain copy
  1. CREATE INDEX username_city_age ON mytable(username,city,age);

如果分別在 usernname,city,age上建立單列索引,讓該表有3個單列索引,查詢時和上述的組合索引效率也會大不一樣,遠遠低於組合索引。雖然此時有了三個索引,但MySQL只能用到其中那個它認為似乎是最有效率的單列索引。

建立這樣的組合索引,其實是相當於分別建立了下面三組組合索引:

usernname,city,age usernname,city usernname 為什麽沒有 city,age這樣的組合索引呢?這是因為MySQL組合索引“最左前綴”的結果。簡單的理解就是只從最左面的開始組合。並不是只要包含這三列的查詢都會用到該組合索引,下面的幾個SQL就會用到這個組合索引:

[css] view plain copy
  1. SELECT * FROM mytable WHREE username="admin" AND city="鄭州"
  2. SELECT * FROM mytable WHREE username="admin"

而下面幾個則不會用到:

[css] view plain copy
  1. SELECT * FROM mytable WHREE age=20 AND city="鄭州"
  2. SELECT * FROM mytable WHREE city="鄭州"

如果對多列進行索引(組合索引),列的順序非常重要,MySQL僅能對索引最左邊的前綴進行有效的查找。

例如:
假設存在組合索引index1(c1,c2),查詢語句select * from t1 where c1=1 and c2=2能夠使用該索引。查詢語句select *from t1 where c1=1也能夠使用該索引。但是,查詢語句select * from t1 where c2=2不能夠使用該索引,因為沒有組合索引的引導列,即要想使用c2列進行查找,必需出現c1等於某值。因此我們在創建組合索引時應該將最常用作限制條件的列放在最左邊,依次遞減。

4、 全文索引

只用於MyISAM 表 對文本域進行索引。字段類型包括char、varchar、text

不過切記對於大容量的數據表,生成全文索引是一個非常消耗時間非常消耗硬盤空間的做法。

[css] view plain copy
  1. CREATE FULLTEXT INDEX indexname ON tablename(column)

查看索引

[css] view plain copy
  1. mysql> show index from tablename;
  2. mysql> show keys from tablename;

建立索引的時機

到這裏我們已經學會了建立索引,那麽我們需要在什麽情況下建立索引呢?

一般來說,在WHERE和JOIN子句中出現的列需要建立索引,例如:在username上創建索引

[css] view plain copy
  1. SELECT * FROM mytable WHREE username="admin" AND city="鄭州"

代碼如下:

[css] view plain copy
  1. SELECT t.Name FROM mytable1 t LEFTJOIN mytable2 m ON t.username=m.username;

此時就需要對兩個表的userame上建立索引。

使用索引的註意事項

剛才提到只有某些時候的LIKE才需建立索引。因為在以通配符%和_開頭作查詢時,MySQL不會使用索引。例如下句會使用索引:

[css] view plain copy
  1. SELECT * FROM mytable WHERE username like‘admin%‘

而下句就不會使用:

[css] view plain copy
  1. SELECT * FROM mytable WHEREt Name like‘%admin‘

不要在列上進行運算,例如

[css] view plain copy
  1. select * from users where YEAR(adddate)<2007;

將在每個行上進行運算,這將導致索引失效而進行全表掃描,因此我們可以改成

[css] view plain copy
  1. select * from users where adddate<‘2007-01-01‘;

總結:

選擇索引列:

a.性能優化過程中,選擇在哪個列上創建索引是最重要的步驟之一。可以考慮使用索引 的主要有 兩種類型的列:在where子句中出現的列,在join子句中出現的列。
b.考慮列中值的分布,索引的列的基數越大,索引的效果越好。
c.使用短索引,如果對字符串列進行索引,應該指定一個前綴長度,可節省大量索引空間,提升查詢速度。

例如:CREATEINDEX username_city_age ON mytable(username(10),city,age);

建表時,usernname長度為 16,這裏用 10。這是因為一般情況下名字的長度不會超過10,這樣會加速索引查詢速度,還會減少索引文件的大小,提高INSERT的更新速度。

d.利用最左前綴
e.不要過度索引,只保持所需的索引。每個額外的索引都要占用額外的磁盤空間,並降低寫操作的性能。 在修改表的內容時,索引必須進行更新,有時可能需要重構,因此,索引越多,所花的時間越長。
MySQL只對以下操作符才使用索引:<,<=,=,>,>=,between,in,
以及某些時候的like(不以通配符%或_開頭的情形)。

以下就是有關Mysql索引的相關理論介紹,下面我們來學習如何慢查詢分析、優化索引和配置

三、mysql性能優化-慢查詢分析、優化索引和配置

基本思路:

(1)性能瓶頸定位

Show命令

慢查詢日誌

explain分析查詢

profiling分析查詢

(2)索引及查詢優化

(3)配置優化

MySQL數據庫最常見的兩個瓶頸是CPU和I/O的瓶頸,CPU在飽和的時候一般發生在數據裝入內存或從磁盤上讀取數據時候。磁盤I/O瓶頸發生在裝入數據遠大於內存容量的時候,如果應用分布在網絡上,那麽查詢量相當大的時候那麽平瓶頸就會出現在網絡上,我們可以用mpstat, iostat, sar和vmstat來查看系統的性能狀態。

除了服務器硬件的性能瓶頸,對於MySQL系統本身,我們可以使用工具來優化數據庫的性能,通常有三種:使用索引,使用EXPLAIN分析查詢以及調整MySQL的內部配置。

1、查詢與索引優化分析

在優化MySQL時,通常需要對數據庫進行分析,常見的分析手段有慢查詢日誌,EXPLAIN 分析查詢,profiling分析以及show命令查詢系統狀態及系統變量,通過定位分析性能的瓶頸,才能更好的優化數據庫系統的性能。

性能瓶頸定位

show命令

可以通過show命令查看MySQL狀態及變量,找到系統的瓶頸:

查看MySQL服務器配置信息mysql> show variables;

查看MySQL服務器運行的各種狀態值mysql> show global status;

[css] view plain copy
  1. # mysqladmin variables -u username -ppassword——顯示系統變量
  2. # mysqladmin extended-status -u username -ppassword——顯示狀態信息

比較全的show命令的使用可參考:mysql>help show

或http://dev.mysql.com/doc/refman/5.7/en/show.html

慢查詢日誌

慢查詢日誌開啟:

在配置文件my.cnf中在[mysqld]一行下面加入3個配置參數,並重啟mysql服務

slow_query_log = 1 //0關閉 1開啟
slow_query_log_file = /usr/local/mysql/data/slow-query.log //慢查詢日誌存放地點

long_query_time = 1 //表示查詢超過1秒才記錄

在my.cnf中添加log-queries-not-using-indexes參數,表示向慢查詢日誌中記錄下沒有使用索引的查詢。

慢查詢日誌開啟方法二:

我們也可以通過命令行設置變量來即時啟動慢日誌查詢

mysql> set global slow_query_log =on;

mysql> set long_query_time = 0.01;

mysql> set global slow_query_log_file= "/usr/local/mysql/data/slow-query.log";

查看慢查詢的設置信息

[css] view plain copy
  1. mysql> show variables like ‘%slow_query_log%‘;
  2. mysql> show variables like ‘%long_query_time%‘;

我們可以通過打開log文件查看得知哪些SQL執行效率低下

[css] view plain copy
  1. [root@mysql data]# cat slow-query.log
[css] view plain copy
  1. # Time: 2016-09-06T14:17:12.582189Z
  2. # User@Host: root[root] @ localhost [] Id: 3
  3. # Query_time: 0.008316 Lock_time: 0.000304 Rows_sent: 1 Rows_examined: 20002
  4. SET timestamp=1473171432;
  5. select * from test1.tb1 where stusex=‘0‘; //沒有使用索引的query
  6. # Time: 2016-09-06T15:54:42.648291Z
  7. # User@Host: root[root] @ localhost [] Id: 14
  8. # Query_time: 0.017319 Lock_time: 0.000612 Rows_sent: 1 Rows_examined: 20001
  9. SET timestamp=1473177282;
  10. select * from test1.tb1 where entertime <> ‘2016-9-3‘; //慢查詢query
[css] view plain copy

select * from test1.tb1 where entertime<> ‘2016-9-3‘; //慢查詢query

從日誌中,可以發現查詢時間超過0.01 秒的SQL,而小於0.01秒的沒有出現在此日誌中。

如果慢查詢日誌中記錄內容很多,可以使用mysqldumpslow工具(MySQL客戶端安裝自帶)來對慢查詢日誌進行分類匯總。mysqldumpslow對日誌文件進行了分類匯總,顯示匯總後摘要結果。

有關mysqldumpslow命令的用法可以參考其幫助:#mysqldumpslow --help

[css] view plain copy
  1. [root@mysql data]# mysqldumpslow -a -s at -r slow-query.log
[css] view plain copy
  1. Reading mysql slow query log from slow-query.log
  2. Count: 1 Time=0.00s (0s) Lock=0.00s (0s) Rows=0.0 (0), 0users@0hosts
  3. Time: 2016-09-06T15:54:42.648291Z
  4. # User@Host: root[root] @ localhost [] Id: 14
  5. # Query_time: 0.017319 Lock_time: 0.000612 Rows_sent: 1 Rows_examined: 20001
  6. SET timestamp=1473177282;
[css] view plain copy
  1. select * from test1.tb1 where entertime <> ‘2016-9-3‘

上面顯示結果中就是一條慢查詢,如何優化呢?

優化前查詢0.01秒

一是在entertime列上創建索引優化查詢

[css] view plain copy
  1. mysql> create index index_entertime on test1.tb1(entertime);

二是優化這個sql查詢語句

[css] view plain copy
  1. mysql> select * from test1.tb1 where entertime < ‘2016-9-3‘ or entertime > ‘2016-9-3‘;

從下圖可以看查詢0.00秒

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

explain分析查詢

使用 EXPLAIN 關鍵字可以模擬優化器執行SQL查詢語句,從而知道MySQL是如何處理你的SQL語句的。這可以幫你分析你的查詢語句或是表結構的性能瓶頸。通過explain命令可以得到:

[css] view plain copy
  1. mysql> explain select * from test1.tb1 where stuname=‘admin‘\G;
  2. *************************** 1. row ***************************
  3. id: 1
  4. select_type: SIMPLE
  5. table: tb1
  6. partitions: NULL
  7. type: ALL //全表掃描
  8. possible_keys: NULL
  9. key: NULL
  10. key_len: NULL
  11. ref: NULL
  12. rows: 19986
  13. filtered: 10.00
  14. Extra: Using where //使用where過濾數據
  15. 1 row in set, 1 warning (0.00 sec)
[css] view plain copy
  1. EXPLAIN字段:
  2. Table:顯示這一行的數據是關於哪張表的
  3. type:這是最重要的字段之一,顯示查詢使用了何種類型。從最好到最差的連接類型為system、const、eq_reg、ref、range、index和ALL
  4. possible_keys:顯示可能應用在這張表中的索引。如果為空,沒有可能的索引。
  5. key:實際使用的索引。如果為NULL,則沒有使用索引。
  6. key_len:使用的索引的長度。在不損失精確性的情況下,長度越短越好
  7. ref:顯示索引的哪一列被使用了,如果可能的話,是一個常數
  8. rows:MySQL認為必須檢索的用來返回請求數據的行數
  9. Extra:關於MYSQL如何解析查詢的額外信息

從上面的explain模擬優化器執行sql語句來看是沒有使用索引查詢的,而是全表掃描

優化方法:在stuname列上創建索引

[css] view plain copy
  1. mysql> create index index_stuname on test1.tb1(stuname);

再次執行explain

顯示結果說明該查詢語句使用了index_stuname索引查詢數據而非全表掃描。

profiling分析查詢

通過慢日誌查詢可以知道哪些SQL語句執行效率低下,通過explain我們可以得知SQL語句的具體執行情況,索引使用等,還可以結合show命令查看執行狀態。如果覺得explain的信息不夠詳細,可以同通過profiling命令得到更準確的SQL執行消耗系統資源的信息。

profiling默認是關閉的。可以通過以下語句查看

[css] view plain copy
  1. mysql> show variables like ‘%profiling%‘; //off表示未開啟

[css] view plain copy
  1. mysql> select @@profiling; //0表示未開啟

打開profiling功能: mysql>set profiling=1; 執行需要測試的sql 語句:

mysql> select @@profiling;

執行要測試的sql語句

[css] view plain copy
  1. mysql> show profile for query 2; //得到對應SQL語句執行的詳細信息

status:是profile裏的狀態,duration:是status狀態下的耗時。因此我們關註的就是那個狀態最耗時,這些狀態中那些可以優化。

當然也可以查看更多的信息如CPU等等

[css] view plain copy
  1. SHOW PROFILE [type [, type] ... ] [FOR QUERY n]
  2. type:
[css] view plain copy
  1. ALL:顯示所有的開銷信息
  2. BLOCK IO:顯示塊IO相關開銷
  3. CPU:顯示用戶CPU時間、系統CPU時間
  4. IPC:顯示發送和接收相關開銷信息
  5. PAGE FAULTS:顯示頁面錯誤相關開銷信息
  6. SWAPS:顯示交換次數相關開銷的信息

測試完成之以後,記得要關閉調試功能,以免影響數據庫的正常使用:

[css] view plain copy
  1. mysql> set profiling=0;

2、配置優化

Mysql參數優化對於不同的網站,及其在線量,訪問量,帖子數量,網絡情況,以及機器硬件配置都有關系,優化不可能一次性完成,需要不斷的觀察以及調試,才有可能得到最佳效果。

下面列出了對性能優化影響較大的主要變量,主要分為連接請求的變量和緩沖區變量

1.連接請求的變量:

(1.)max_connections

MySQL的最大連接數,如果服務器的並發連接請求量比較大,建議調高此值,以增加並行連接數量,當然這建立在機器能支撐的情況下,因為如果連接數越多, MySQL會為每個連接提供連接緩沖區,就會開銷越多的內存,所以要適當調整該值,不能盲目提高設值。

數值過小會經常出現ERROR 1040: Too many connections錯誤,可以過mysql> showstatus like ‘connections‘;通配符查看當前狀態的連接數量(試圖連接到MySQL(不管是否連接成功)的連接數),以定奪該值的大小。

[css] view plain copy
  1. mysql>show variables like ‘max_connections’ 最大連接數
  2. mysql>show status like ‘max_used_connections’ 響應的連接數
  3. max_used_connections / max_connections * 100% (理想值≈ 85%)

如果max_used_connections跟max_connections相同那麽就是max_connections設置過低或者超過服務器負載上限了,低於10%則設置過大。

如何設置max_connections?

修改/etc/my.cnf文件,在[mysqld]下面添加如下內容,如設置最大連接數為1024

[css] view plain copy
  1. max_connections = 1024

重啟mysql服務

(2.)back_log

MySQL能暫存的連接數量。當主要MySQL線程在一個很短時間內得到非常多的連接請求,它就會起作用。如果MySQL的連接數據達到max_connections時,新來的請求將會被存在堆棧中,以等待某一連接釋放資源,該堆棧的數量即back_log,如果等待連接的數量超過back_log,將不被授予連接資源。

back_log值指出在MySQL暫時停止回答新請求之前的短時間內有多少個請求可以被存在堆棧中。只有如果期望在一個短時間內有很多連接,你需要增加它。

當觀察你主機進程列表(mysql> show full processlist),發現大量

xxxxx | unauthenticated user |xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待連接進程時,就要加大back_log的值了或加大max_connections的值。

通過mysql> show variables like ‘back_log‘;查看back_log的設置

如何設置back_log?

修改/etc/my.cnf文件,在[mysqld]下面添加如下內容,如設置最大連接數為1024

[css] view plain copy
  1. back_log = 數值

重啟mysql服務

(3.)wait_timeout和interactive_timeout

wait_timeout -- 指的是MySQL在關閉一個非交互的連接之前所要等待的秒數

interactive_time -- 指的是mysql在關閉一個交互的連接之前所要等待的秒數,比如我們在終端上進入mysql管理,使用的即使交互的連接,這時候,如果沒有操作的時間超過了interactive_time設置的時間就會自動斷開。默認數值是28800,可調優為7200。

對性能的影響:

wait_timeout:

(1)如果設置大小,那麽連接關閉的很快,從而使一些持久的連接不起作用

(2)如果設置太大,容易造成連接打開時間過長,在show processlist時,能看到太多的sleep狀態的連接,從而造成too many connections錯誤

(3)一般希望wait_timeout盡可能地低

interactive_timeout的設置將要對你的webapplication沒有多大的影響

查看wait_timeout和interactive_timeout

[css] view plain copy
  1. mysql> show variables like ‘%wait_tmeout%‘;
  2. mysql> show variables like ‘%interactive_timeout%‘;

如何設置wait_timeout和interactive_timeout?

修改/etc/my.cnf文件,在[mysqld]下面添加如下內容

[css] view plain copy
  1. wait_timeout=100
  2. interactive_timeout=100

重啟MySQL Server進入後,查看設置已經生效。

2.綬沖區變量

全局緩沖:

(1.)key_buffer_size

key_buffer_size指定索引緩沖區的大小,它決定索引處理的速度,尤其是索引讀的速度。通過檢查狀態值Key_read_requests和Key_reads,可以知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該盡可能的低,至少是1:100,1:1000更好(上述狀態值可以使用SHOWSTATUS LIKE ‘key_read%’獲得)。


一共有14個索引讀取請求,有5個請求在內存中沒有找到直接從硬盤讀取索引,計算索引未命中緩存的概率:

[css] view plain copy
  1. key_cache_miss_rate = Key_reads / Key_read_requests * 100% =50%

key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表,但是內部的臨時磁盤表是MyISAM表,也要使用該值。可以使用檢查狀態值created_tmp_disk_tables得知詳情。

如何調整key_buffer_size

默認配置數值是8388608(8M),主機有4GB內存,可以調優值為268435456(256MB)

修改/etc/my.cnf文件,在[mysqld]下面添加如下內容

[css] view plain copy
  1. key_buffer_size=268435456或key_buffer_size=256M

重啟MySQL Server進入後,查看設置已經生效。

(2.)query_cache_size(查詢緩存簡稱QC)

使用查詢緩沖,MySQL將查詢結果存放在緩沖區中,今後對於同樣的SELECT語句(區分大小寫),將直接從緩沖區中讀取結果。

一個SQL查詢如果以select開頭,那麽MySQL服務器將嘗試對其使用查詢緩存。

註:兩個SQL語句,只要相差哪怕是一個字符(例如大小寫不一樣;多一個空格等),那麽這兩個SQL將使用不同的一個CACHE。

通過檢查狀態值’Qcache%’,可以知道query_cache_size設置是否合理(上述狀態值可以使用SHOW STATUS LIKE ‘Qcache%’獲得)。

Qcache_free_blocks:緩存中相鄰內存塊的個數。如果該值顯示較大,則說明Query Cache 中的內存碎片較多了,FLUSH QUERY CACHE會對緩存中的碎片進行整理,從而得到一個空閑塊。

註意:當一個表被更新之後,和它相關的cache blocks將被free。但是這個block依然可能存在隊列中,除非是在隊列的尾部。可以用FLUSH QUERY CACHE語句來清空free blocks
Qcache_free_memory:Query Cache 中目前剩余的內存大小。通過這個參數我們可以較為準確的觀察出當前系統中的Query Cache 內存大小是否足夠,是需要增加還是過多了。
Qcache_hits:表示有多少次命中緩存。我們主要可以通過該值來驗證我們的查詢緩存的效果。數字越大,緩存效果越理想。
Qcache_inserts:表示多少次未命中然後插入,意思是新來的SQL請求在緩存中未找到,不得不執行查詢處理,執行查詢處理後把結果insert到查詢緩存中。這樣的情況的次數越多,表示查詢緩存應用到的比較少,效果也就不理想。當然系統剛啟動後,查詢緩存是空的,這很正常。
Qcache_lowmem_prunes:多少條Query 因為內存不足而被清除出QueryCache。通過“Qcache_lowmem_prunes”和“Qcache_free_memory”相互結合,能夠更清楚的了解到我們系統中Query Cache 的內存大小是否真的足夠,是否非常頻繁的出現因為內存不足而有Query 被換出。這個數字最好長時間來看;如果這個數字在不斷增長,就表示可能碎片非常嚴重,或者內存很少。(上面的free_blocks和free_memory可以告訴您屬於哪種情況)
Qcache_not_cached:不適合進行緩存的查詢的數量,通常是由於這些查詢不是 SELECT 語句或者用了now()之類的函數。
Qcache_queries_in_cache:當前Query Cache 中cache 的Query 數量;
Qcache_total_blocks:當前Query Cache 中的block 數量;。

我們再查詢一下服務器關於query_cache的配置:

上圖可以看出query_cache_type為off表示不緩存任何查詢

各字段的解釋:

query_cache_limit:超過此大小的查詢將不緩存
query_cache_min_res_unit:緩存塊的最小大小 ,query_cache_min_res_unit的配置是一柄”雙刃劍”,默認是4KB,設置值大對大數據查詢有好處,但如果你的查詢都是小數據查詢,就容易造成內存碎片和浪費。
query_cache_size:查詢緩存大小 (註:QC存儲的最小單位是1024 byte,所以如果你設定了一個不是1024的倍數的值,這個值會被四舍五入到最接近當前值的等於1024的倍數的值。)
query_cache_type:緩存類型,決定緩存什麽樣的查詢,註意這個值不能隨便設置,必須設置為數字,可選項目以及說明如下:

如果設置為0,那麽可以說,你的緩存根本就沒有用,相當於禁用了。

如果設置為1,將會緩存所有的結果,除非你的select語句使用SQL_NO_CACHE禁用了查詢緩存。

如果設置為2,則只緩存在select語句中通過SQL_CACHE指定需要緩存的查詢。

修改/etc/my.cnf,配置完後的部分文件如下:

[css] view plain copy
  1. query_cache_size=256M
  2. query_cache_type=1

保存文件,重新啟動MYSQL服務,然後通過如下查詢來驗證是否真正開啟了:

query_cache_wlock_invalidate:當有其他客戶端正在對MyISAM表進行寫操作時,如果查詢在querycache中,是否返回cache結果還是等寫操作完成再讀表獲取結果。

[css] view plain copy
  1. 查詢緩存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
  2. 如果查詢緩存碎片率超過20%,可以用FLUSH QUERY CACHE整理緩存碎片,或者試試減小query_cache_min_res_unit,如果你的查詢都是小數據量的話。
  3. 查詢緩存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100%
  4. 查詢緩存利用率在25%以下的話說明query_cache_size設置的過大,可適當減小;查詢緩存利用率在80%以上而且Qcache_lowmem_prunes > 50的話說明query_cache_size可能有點小,要不就是碎片太多。
  5. 查詢緩存命中率 = Qcache_hits/(Qcache_hits +Qcache_inserts) * 100%

Query Cache的限制

a) 所有子查詢中的外部查詢SQL 不能被Cache;
b) 在Procedure,Function 以及Trigger 中的Query 不能被Cache;
c) 包含其他很多每次執行可能得到不一樣結果的函數的Query不能被Cache。
鑒於上面的這些限制,在使用Query Cache 的過程中,建議通過精確設置的方式來使用,僅僅讓合適的表的數據可以進入Query Cache,僅僅讓某些Query的查詢結果被Cache。

如何設置query_cache_size?

修改/etc/my.cnf文件,在[mysqld]下面添加如下內容

[css] view plain copy
  1. query_cache_size=256M
  2. query_cache_type=1

重啟MySQL Server進入後,查看設置已經生效。

(3.)max_connect_errors是一個MySQL中與安全有關的計數器值,它負責阻止過多嘗試失敗的客戶端以防止暴力破解密碼的情況,當超過指定次數,MYSQL服務器將禁止host的連接請求,直到mysql服務器重啟或通過flush hosts命令清空此host的相關信息。max_connect_errors的值與性能並無太大關系。

修改/etc/my.cnf文件,在[mysqld]下面添加如下內容

[css] view plain copy
  1. max_connect_errors=20

重啟MySQL Server進入後,查看設置已經生效。

(4.)sort_buffer_size

每個需要進行排序的線程分配該大小的一個緩沖區。增加這值加速ORDER BY或GROUPBY操作。

Sort_Buffer_Size 是一個connection級參數,在每個connection(session)第一次需要使用這個buffer的時候,一次性分配設置的內存。
Sort_Buffer_Size 並不是越大越好,由於是connection級的參數,過大的設置+高並發可能會耗盡系統內存資源。例如:500個連接將會消耗 500*sort_buffer_size(2M)=1G內存

例如設置sort_buffer_size

修改/etc/my.cnf文件,在[mysqld]下面添加如下內容

[css] view plain copy
  1. sort_buffer_size = 2M

重啟MySQL Server進入後,查看設置已經生效。

(5.) max_allowed_packet = 32M

MySQL根據配置文件會限制Server接受的數據包大小。有時候大的插入和更新會受 max_allowed_packet 參數限制,導致寫入或者更新失敗。最大值是1GB,必須設置1024的倍數。
(6.)join_buffer_size = 2M

用於表間關聯緩存的大小,和sort_buffer_size一樣,該參數對應的分配內存也是每個連接獨享。

(7.)thread_cache_size = 300

服務器線程緩存,這個值表示可以重新利用保存在緩存中線程的數量,當斷開連接時,那麽客戶端的線程將被放到緩存中以響應下一個客戶而不是銷毀(前提是緩存數未達上限),如果線程重新被請求,那麽請求將從緩存中讀取,如果緩存中是空的或者是新的請求,那麽這個線程將被重新創建,如果有很多新的線程,增加這個值可以改善系統性能.通過比較 Connections 和 Threads_created 狀態的變量,可以看到這個變量的作用。設置規則如下:1GB 內存配置為8,2GB配置為16,3GB配置為32,4GB或更高內存,可配置更大。服務器處理此客戶的線程將會緩存起來以響應下一個客戶而不是銷毀(前提是緩存數未達上限)

試圖連接到MySQL(不管是否連接成功)的連接數

[css] view plain copy
  1. Threads_cached :代表當前此時此刻線程緩存中有多少空閑線程。
  2. Threads_connected :代表當前已建立連接的數量,因為一個連接就需要一個線程,所以也可以看成當前被使用的線程數。
  3. Threads_created :代表從最近一次服務啟動,已創建線程的數量,如果發現Threads_created值過大的話,表明MySQL服務器一直在創建線程,這也是比較耗資源,可以適當增加配置文件中thread_cache_size值。
  4. Threads_running :代表當前激活的(非睡眠狀態)線程數。並不是代表正在使用的線程數,有時候連接已建立,但是連接處於sleep狀態。

3.配置InnoDB的幾個變量

(1.)innodb_buffer_pool_size

對於InnoDB表來說,innodb_buffer_pool_size的作用就相當於key_buffer_size對於MyISAM表的作用一樣。InnoDB使用該參數指定大小的內存來緩沖數據和索引。對於單獨的MySQL數據庫服務器,最大可以把該值設置成物理內存的80%。根據MySQL手冊,對於2G內存的機器,推薦值是1G(50%)。 如果你的數據量不大,並且不會暴增,那麽無需把 innodb_buffer_pool_size 設置的太大了。

設置innodb_buffer_pool_size

修改/etc/my.cnf文件,在[mysqld]下面添加如下內容

[css] view plain copy
  1. innodb_buffer_pool_size = 2048M

重啟MySQL Server進入後,查看設置已經生效。

(2.)innodb_flush_log_at_trx_commit

主要控制了innodb將log buffer中的數 1寫入日誌文件並flush磁盤的時間點,取值分別為0、1、2三個。0,表示當事務提交時,不做日誌寫入操作,而是每秒鐘將log buffer中的數據寫入日誌文件並flush磁盤一次;1,則在每秒鐘或是每次事物的提交都會引起日誌文件寫入、flush磁盤的操作,確保了事務的ACID;設置為2,每次事務提交引起寫入日誌文件的動作,但每秒鐘完成一次flush磁盤操作。

實際測試發現,該值對插入數據的速度影響非常大,設置為2時插入10000條記錄只需要2秒,設置為0時只需要1秒,而設置為1時則需要229秒。因此,MySQL手冊也建議盡量將插入操作合並成一個事務,這樣可以大幅提高速度。

根據MySQL手冊,在允許丟失最近部分事務的危險的前提下,可以把該值設為0或2。

(3.)innodb_thread_concurrency = 0

此參數用來設置innodb線程的並發數量,默認值為0表示不限制,若要設置則與服務器的CPU核數相同或是cpu的核數的2倍,建議用默認設置,一般為8.

(4.)innodb_log_buffer_size

此參數確定些日誌文件所用的內存大小,以M為單位。緩沖區更大能提高性能,對於較大的事務,可以增大緩存大小。

[css] view plain copy
  1. innodb_log_buffer_size=32M

(5.)innodb_log_file_size = 50M

此參數確定數據日誌文件的大小,以M為單位,更大的設置可以提高性能.

(6.)innodb_log_files_in_group= 3

為提高性能,MySQL可以以循環方式將日誌文件寫到多個文件。推薦設置為3

(7.)read_buffer_size = 1M

MySql讀入緩沖區大小。對表進行順序掃描的請求將分配一個讀入緩沖區,MySql會為它分配一段內存緩沖區。如果對表的順序掃描請求非常頻繁,並且你認為頻繁掃描進行得太慢,可以通過增加該變量值以及內存緩沖區大小提高其性能。和 sort_buffer_size一樣,該參數對應的分配內存也是每個連接獨享。

(8.)read_rnd_buffer_size = 16M

MySql 的隨機讀(查詢操作)緩沖區大小。當按任意順序讀取行時(例如,按照排序順序),將分配一個隨機讀緩存區。進行排序查詢時,MySql會首先掃描一遍該緩沖,以避免磁盤搜索,提高查詢速度,如果需要排序大量數據,可適當調高該值。但MySql會為每個客戶連接發放該緩沖空間,所以應盡量適當設置該值,以避免內存開銷過大。
註:順序讀是指根據索引的葉節點數據就能順序地讀取所需要的行數據。隨機讀是指一般需要根據輔助索引葉節點中的主鍵尋找實際行數據,而輔助索引和主鍵所在的數據段不同,因此訪問方式是隨機的。

(9.)bulk_insert_buffer_size = 64M

批量插入數據緩存大小,可以有效提高插入效率,默認為8M

(10.)binary log

[css] view plain copy
  1. log-bin=/usr/local/mysql/data/mysql-bin

binlog_cache_size = 2M //為每個session 分配的內存,在事務過程中用來存儲二進制日誌的緩存, 提高記錄bin-log的效率。沒有什麽大事務,dml也不是很頻繁的情況下可以設置小一點,如果事務大而且多,dml操作也頻繁,則可以適當的調大一點。前者建議是--1M,後者建議是:即 2--4M

max_binlog_cache_size = 8M //表示的是binlog 能夠使用的最大cache 內存大小

max_binlog_size= 512M //指定binlog日誌文件的大小,如果當前的日誌大小達到max_binlog_size,還會自動創建新的二進制日誌。你不能將該變量設置為大於1GB或小於4096字節。默認值是1GB。在導入大容量的sql文件時,建議關閉sql_log_bin,否則硬盤扛不住,而且建議定期做刪除。

expire_logs_days = 7 //定義了mysql清除過期日誌的時間。
二進制日誌自動刪除的天數。默認值為0,表示“沒有自動刪除”。

mysqladmin flush-logs 也可以重新開始新的binarylog

在優化之前執行mysqlslap工具進行測試

[css] view plain copy
  1. mysql> mysqlslap --defaults-file=/etc/my.cnf --concurrency=10 --iterations=1 --create-schema=‘tables‘ --query=‘select * from tables.tb1‘ --engine=innodb --number-of-queries=2000 -uroot -ppwd123 –verbose;

顯示結果:

優化之後執行mysqlslap工具進行測試

相關優化參數總結:

[css] view plain copy
    1. [mysqld]
    2. slow_query_log = 1
    3. slow_query_log_file = /usr/local/mysql/data/slow-query.log
    4. long_query_time = 1
    5. log-queries-not-using-indexes
    6. max_connections = 1024
    7. back_log = 128
    8. wait_timeout = 60
    9. interactive_timeout = 7200
    10. key_buffer_size=256M
    11. query_cache_size = 256M
    12. query_cache_type=1
    13. query_cache_limit=50M
    14. max_connect_errors=20
    15. sort_buffer_size = 2M
    16. max_allowed_packet=32M
    17. join_buffer_size=2M
    18. thread_cache_size=200
    19. innodb_buffer_pool_size = 2048M
    20. innodb_flush_log_at_trx_commit = 1
    21. innodb_log_buffer_size=32M
    22. innodb_log_file_size=128M
    23. innodb_log_files_in_group=3
    24. log-bin=mysql-bin
    25. binlog_cache_size=2M
    26. max_binlog_cache_size=8M
    27. max_binlog_size=512M
    28. expire_logs_days=7
    29. read_buffer_size=1M
    30. read_rnd_buffer_size=16M
    31. bulk_insert_buffer_size=64M
    32. log-error = /usr/local/mysql/data/mysqld.err

MySQL影響性能的因素原因以及性能優化配置詳解