MySQL優(yōu)化全攻略-相關(guān)數(shù)據(jù)庫(kù)命令
更新時(shí)間:2006年11月25日 00:00:00 作者:
接下來(lái)我們要討論的是數(shù)據(jù)庫(kù)性能優(yōu)化的另一方面,即運(yùn)用數(shù)據(jù)庫(kù)服務(wù)器內(nèi)建的工具輔助性能分析和優(yōu)化。
▲ SHOW
執(zhí)行下面這個(gè)命令可以了解服務(wù)器的運(yùn)行狀態(tài):
mysql >show status;
該命令將顯示出一長(zhǎng)列狀態(tài)變量及其對(duì)應(yīng)的值,其中包括:被中止訪(fǎng)問(wèn)的用戶(hù)數(shù)量,被中止的連接數(shù)量,嘗試連接的次數(shù),并發(fā)連接數(shù)量最大值,以及其他許多有用的信息。這些信息對(duì)于確定系統(tǒng)問(wèn)題和效率低下的原因是十分有用的。
SHOW命令除了能夠顯示出MySQL服務(wù)器整體狀態(tài)信息之外,它還能夠顯示出有關(guān)日志文件、指定數(shù)據(jù)庫(kù)、表、索引、進(jìn)程和許可權(quán)限表的寶貴信息。請(qǐng)?jiān)L問(wèn)http://www.mysql.com/doc/S/H/SHOW.html了解更多信息。
▲ EXPLAIN
EXPLAIN能夠分析SELECT命令的處理過(guò)程。這不僅對(duì)于決定是否要為表加上索引很有用,而且對(duì)于了解MySQL處理復(fù)雜連接的過(guò)程也很有用。
下面這個(gè)例子顯示了如何用EXPLAIN提供的信息逐步地優(yōu)化連接查詢(xún)。(本例來(lái)自MySQL文檔,見(jiàn)http://www.mysql.com/doc/E/X/EXPLAIN.html。原文寫(xiě)到這里似乎有點(diǎn)潦草了事,特加上此例。)
假定用EXPLAIN分析的SELECT命令如下所示:
EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,
tt.ProjectReference, tt.EstimatedShipDate,
tt.ActualShipDate, tt.ClientID,
tt.ServiceCodes, tt.RepetitiveID,
tt.CurrentProcess, tt.CurrentDPPerson,
tt.RecordVolume, tt.DPPrinted, et.COUNTRY,
et_1.COUNTRY, do.CUSTNAME
FROM tt, et, et AS et_1, do
WHERE tt.SubmitTime IS NULL
AND tt.ActualPC = et.EMPLOYID
AND tt.AssignedPC = et_1.EMPLOYID
AND tt.ClientID = do.CUSTNMBR;
SELECT命令中出現(xiàn)的表定義如下:
※表定義
表 列 列類(lèi)型
tt ActualPC CHAR(10)
tt AssignedPC CHAR(10)
tt ClientID CHAR(10)
et EMPLOYID CHAR(15)
do CUSTNMBR CHAR(15)
※索引
表 索引
tt ActualPC
tt AssignedPC
tt ClientID
et EMPLOYID (主鍵)
do CUSTNMBR (主鍵)
※tt.ActualPC值分布不均勻
在進(jìn)行任何優(yōu)化之前,EXPLAIN對(duì)SELECT執(zhí)行分析的結(jié)果如下:
table type possible_keys key key_len ref rows Extra
et ALL PRIMARY NULL NULL NULL 74
do ALL PRIMARY NULL NULL NULL 2135
et_1 ALL PRIMARY NULL NULL NULL 74
tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872
range checked for each record (key map: 35)
每一個(gè)表的type都是ALL,它表明MySQL為每一個(gè)表進(jìn)行了完全連接!這個(gè)操作是相當(dāng)耗時(shí)的,因?yàn)榇幚硇械臄?shù)量達(dá)到每一個(gè)表行數(shù)的乘積!即,這里的總處理行數(shù)為74 * 2135 * 74 * 3872 = 45,268,558,720。
這里的問(wèn)題之一在于,如果數(shù)據(jù)庫(kù)列的聲明不同,MySQL(還)不能有效地運(yùn)用列的索引。在這個(gè)問(wèn)題上,VARCHAR和CHAR是一樣的,除非它們聲明的長(zhǎng)度不同。由于tt.ActualPC聲明為CHAR(10),而et.EMPLOYID聲明為CHAR(15),因此這里存在列長(zhǎng)度不匹配問(wèn)題。
為了解決這兩個(gè)列的長(zhǎng)度不匹配問(wèn)題,用ALTER TABLE命令把ActualPC列從10個(gè)字符擴(kuò)展到15字符,如下所示:
mysql > ALTER TABLE tt MODIFY ActualPC VARCHAR(15);
現(xiàn)在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)了,執(zhí)行EXPLAIN進(jìn)行分析得到的結(jié)果如下所示:
table type possible_keys key key_len ref rows Extra
tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872 where used
do ALL PRIMARY NULL NULL NULL 2135
range checked for each record (key map: 1)
et_1 ALL PRIMARY NULL NULL NULL 74
range checked for each record (key map: 1)
et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
這還算不上完美,但已經(jīng)好多了(行數(shù)的乘積現(xiàn)在少了一個(gè)系數(shù)74)?,F(xiàn)在這個(gè)SQL命令執(zhí)行大概需要數(shù)秒鐘時(shí)間。
為了避免tt.AssignedPC = et_1.EMPLOYID以及tt.ClientID = do.CUSTNMBR比較中的列長(zhǎng)度不匹配,我們可以進(jìn)行如下改動(dòng):
mysql > ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),
MODIFY ClientID VARCHAR(15);
現(xiàn)在EXPLAIN顯示的結(jié)果如下:
table type possible_keys key key_len ref rows Extra
et ALL PRIMARY NULL NULL NULL 74
tt ref AssignedPC,ClientID,ActualPC ActualPC 15 et.EMPLOYID 52 where used
et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1
這個(gè)結(jié)果已經(jīng)比較令人滿(mǎn)意了。
余下的問(wèn)題在于,默認(rèn)情況下,MySQL假定tt.ActualPC列的值均勻分布,而事實(shí)上tt表的情況并非如此。幸而,我們可以很容易地讓MySQL知道這一點(diǎn):
shell > myisamchk --analyze PATH_TO_MYSQL_DATABASE/tt
shell > mysqladmin refresh
現(xiàn)在這個(gè)連接操作已經(jīng)非常理想,EXPLAIN分析的結(jié)果如下:
table type possible_keys key key_len ref rows Extra
tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872 where used
et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1
▲ OPTIMIZE
OPTIMIZE能夠恢復(fù)和整理磁盤(pán)空間以及數(shù)據(jù)碎片,一旦對(duì)包含變長(zhǎng)行的表進(jìn)行了大量的更新或者刪除,進(jìn)行這個(gè)操作就非常有必要了。OPTIMIZE當(dāng)前只能用于MyISAM和BDB表。
結(jié)束語(yǔ):從編譯數(shù)據(jù)庫(kù)服務(wù)器開(kāi)始、貫穿整個(gè)管理過(guò)程,能夠改善MySQL性能的因素實(shí)在非常多,本文只涉及了其中很小的一部分。盡管如此,我們希望本文討論的內(nèi)容能夠?qū)δ阌兴鶐椭?nbsp;
//copy者注:
時(shí)間不夠,所以格式上有點(diǎn)問(wèn)題~~,請(qǐng)大家看詳細(xì)的英文原文:http://www.devshed.com/Server_Side/MySQL/Optimize/
或者看看chinabyte的文章好了:
http://www.chinabyte.com/builder/detail.shtm?buiid=1012&parid=1
哈哈~從這點(diǎn)能不能看出來(lái)我是全心全意為大家服務(wù)的
▲ SHOW
執(zhí)行下面這個(gè)命令可以了解服務(wù)器的運(yùn)行狀態(tài):
mysql >show status;
該命令將顯示出一長(zhǎng)列狀態(tài)變量及其對(duì)應(yīng)的值,其中包括:被中止訪(fǎng)問(wèn)的用戶(hù)數(shù)量,被中止的連接數(shù)量,嘗試連接的次數(shù),并發(fā)連接數(shù)量最大值,以及其他許多有用的信息。這些信息對(duì)于確定系統(tǒng)問(wèn)題和效率低下的原因是十分有用的。
SHOW命令除了能夠顯示出MySQL服務(wù)器整體狀態(tài)信息之外,它還能夠顯示出有關(guān)日志文件、指定數(shù)據(jù)庫(kù)、表、索引、進(jìn)程和許可權(quán)限表的寶貴信息。請(qǐng)?jiān)L問(wèn)http://www.mysql.com/doc/S/H/SHOW.html了解更多信息。
▲ EXPLAIN
EXPLAIN能夠分析SELECT命令的處理過(guò)程。這不僅對(duì)于決定是否要為表加上索引很有用,而且對(duì)于了解MySQL處理復(fù)雜連接的過(guò)程也很有用。
下面這個(gè)例子顯示了如何用EXPLAIN提供的信息逐步地優(yōu)化連接查詢(xún)。(本例來(lái)自MySQL文檔,見(jiàn)http://www.mysql.com/doc/E/X/EXPLAIN.html。原文寫(xiě)到這里似乎有點(diǎn)潦草了事,特加上此例。)
假定用EXPLAIN分析的SELECT命令如下所示:
EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,
tt.ProjectReference, tt.EstimatedShipDate,
tt.ActualShipDate, tt.ClientID,
tt.ServiceCodes, tt.RepetitiveID,
tt.CurrentProcess, tt.CurrentDPPerson,
tt.RecordVolume, tt.DPPrinted, et.COUNTRY,
et_1.COUNTRY, do.CUSTNAME
FROM tt, et, et AS et_1, do
WHERE tt.SubmitTime IS NULL
AND tt.ActualPC = et.EMPLOYID
AND tt.AssignedPC = et_1.EMPLOYID
AND tt.ClientID = do.CUSTNMBR;
SELECT命令中出現(xiàn)的表定義如下:
※表定義
表 列 列類(lèi)型
tt ActualPC CHAR(10)
tt AssignedPC CHAR(10)
tt ClientID CHAR(10)
et EMPLOYID CHAR(15)
do CUSTNMBR CHAR(15)
※索引
表 索引
tt ActualPC
tt AssignedPC
tt ClientID
et EMPLOYID (主鍵)
do CUSTNMBR (主鍵)
※tt.ActualPC值分布不均勻
在進(jìn)行任何優(yōu)化之前,EXPLAIN對(duì)SELECT執(zhí)行分析的結(jié)果如下:
table type possible_keys key key_len ref rows Extra
et ALL PRIMARY NULL NULL NULL 74
do ALL PRIMARY NULL NULL NULL 2135
et_1 ALL PRIMARY NULL NULL NULL 74
tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872
range checked for each record (key map: 35)
每一個(gè)表的type都是ALL,它表明MySQL為每一個(gè)表進(jìn)行了完全連接!這個(gè)操作是相當(dāng)耗時(shí)的,因?yàn)榇幚硇械臄?shù)量達(dá)到每一個(gè)表行數(shù)的乘積!即,這里的總處理行數(shù)為74 * 2135 * 74 * 3872 = 45,268,558,720。
這里的問(wèn)題之一在于,如果數(shù)據(jù)庫(kù)列的聲明不同,MySQL(還)不能有效地運(yùn)用列的索引。在這個(gè)問(wèn)題上,VARCHAR和CHAR是一樣的,除非它們聲明的長(zhǎng)度不同。由于tt.ActualPC聲明為CHAR(10),而et.EMPLOYID聲明為CHAR(15),因此這里存在列長(zhǎng)度不匹配問(wèn)題。
為了解決這兩個(gè)列的長(zhǎng)度不匹配問(wèn)題,用ALTER TABLE命令把ActualPC列從10個(gè)字符擴(kuò)展到15字符,如下所示:
mysql > ALTER TABLE tt MODIFY ActualPC VARCHAR(15);
現(xiàn)在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)了,執(zhí)行EXPLAIN進(jìn)行分析得到的結(jié)果如下所示:
table type possible_keys key key_len ref rows Extra
tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872 where used
do ALL PRIMARY NULL NULL NULL 2135
range checked for each record (key map: 1)
et_1 ALL PRIMARY NULL NULL NULL 74
range checked for each record (key map: 1)
et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
這還算不上完美,但已經(jīng)好多了(行數(shù)的乘積現(xiàn)在少了一個(gè)系數(shù)74)?,F(xiàn)在這個(gè)SQL命令執(zhí)行大概需要數(shù)秒鐘時(shí)間。
為了避免tt.AssignedPC = et_1.EMPLOYID以及tt.ClientID = do.CUSTNMBR比較中的列長(zhǎng)度不匹配,我們可以進(jìn)行如下改動(dòng):
mysql > ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),
MODIFY ClientID VARCHAR(15);
現(xiàn)在EXPLAIN顯示的結(jié)果如下:
table type possible_keys key key_len ref rows Extra
et ALL PRIMARY NULL NULL NULL 74
tt ref AssignedPC,ClientID,ActualPC ActualPC 15 et.EMPLOYID 52 where used
et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1
這個(gè)結(jié)果已經(jīng)比較令人滿(mǎn)意了。
余下的問(wèn)題在于,默認(rèn)情況下,MySQL假定tt.ActualPC列的值均勻分布,而事實(shí)上tt表的情況并非如此。幸而,我們可以很容易地讓MySQL知道這一點(diǎn):
shell > myisamchk --analyze PATH_TO_MYSQL_DATABASE/tt
shell > mysqladmin refresh
現(xiàn)在這個(gè)連接操作已經(jīng)非常理想,EXPLAIN分析的結(jié)果如下:
table type possible_keys key key_len ref rows Extra
tt ALL AssignedPC,ClientID,ActualPC NULL NULL NULL 3872 where used
et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1
▲ OPTIMIZE
OPTIMIZE能夠恢復(fù)和整理磁盤(pán)空間以及數(shù)據(jù)碎片,一旦對(duì)包含變長(zhǎng)行的表進(jìn)行了大量的更新或者刪除,進(jìn)行這個(gè)操作就非常有必要了。OPTIMIZE當(dāng)前只能用于MyISAM和BDB表。
結(jié)束語(yǔ):從編譯數(shù)據(jù)庫(kù)服務(wù)器開(kāi)始、貫穿整個(gè)管理過(guò)程,能夠改善MySQL性能的因素實(shí)在非常多,本文只涉及了其中很小的一部分。盡管如此,我們希望本文討論的內(nèi)容能夠?qū)δ阌兴鶐椭?nbsp;
//copy者注:
時(shí)間不夠,所以格式上有點(diǎn)問(wèn)題~~,請(qǐng)大家看詳細(xì)的英文原文:http://www.devshed.com/Server_Side/MySQL/Optimize/
或者看看chinabyte的文章好了:
http://www.chinabyte.com/builder/detail.shtm?buiid=1012&parid=1
哈哈~從這點(diǎn)能不能看出來(lái)我是全心全意為大家服務(wù)的
您可能感興趣的文章:
- MySQL優(yōu)化必須調(diào)整的10項(xiàng)配置
- mysql優(yōu)化連接數(shù)防止訪(fǎng)問(wèn)量過(guò)高的方法
- mysql優(yōu)化配置參數(shù)
- mysql優(yōu)化limit查詢(xún)語(yǔ)句的5個(gè)方法
- MySQL優(yōu)化GROUP BY方案
- MySQL優(yōu)化總結(jié)-查詢(xún)總條數(shù)
- MySQL優(yōu)化常用的19種有效方法(推薦!)
- MySQL優(yōu)化配置文件my.ini(discuz論壇)
- 21條MySQL優(yōu)化建議(經(jīng)驗(yàn)總結(jié))
- MySQL數(shù)據(jù)庫(kù)配置優(yōu)化的方案
相關(guān)文章
MySql統(tǒng)計(jì)函數(shù)COUNT的具體使用詳解
本文主要介紹了MySql統(tǒng)計(jì)函數(shù)COUNT的具體使用詳解,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2022-08-08提高M(jìn)ySQL 查詢(xún)效率的三個(gè)技巧
MySQL由于它本身的小巧和操作的高效, 在數(shù)據(jù)庫(kù)應(yīng)用中越來(lái)越多的被采用.我在開(kāi)發(fā)一個(gè)P2P應(yīng)用的時(shí)候曾經(jīng)使用MySQL來(lái)保存P2P節(jié)點(diǎn),由于P2P的應(yīng)用中,結(jié)點(diǎn)數(shù)動(dòng)輒上萬(wàn)個(gè),而且節(jié)點(diǎn)變化頻繁,因此一定要保持查詢(xún)和插入的高效.以下是我在使用過(guò)程中做的提高效率的三個(gè)有效的嘗試. 1. 使用statement進(jìn)行綁定查詢(xún) 2. 隨機(jī)的獲取記錄 3. 使用連接池管理連接.2008-04-04MySQL中的行級(jí)鎖、表級(jí)鎖、頁(yè)級(jí)鎖
這篇文章主要介紹了MySQL中的行級(jí)鎖、表級(jí)鎖、頁(yè)級(jí)鎖,以及分享了多種避免死鎖的方法,感興趣的小伙伴們可以參考一下2016-01-01淺談mysql通配符進(jìn)行模糊查詢(xún)的實(shí)現(xiàn)方法
這篇文章主要介紹了淺談mysql通配符進(jìn)行模糊查詢(xún),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2020-07-07低版本Druid連接池+MySQL驅(qū)動(dòng)8.0導(dǎo)致線(xiàn)程阻塞、性能受限
應(yīng)用升級(jí)MySQL驅(qū)動(dòng)8.0后,在并發(fā)量較高時(shí),查看監(jiān)控打點(diǎn),Druid連接池拿到連接并執(zhí)行SQL的時(shí)間大部分都超過(guò)200ms,本文就解決一下這個(gè)問(wèn)題2021-07-07