在如今的互聯(lián)網(wǎng)時(shí)代，數(shù)據(jù)的管理和使用相當(dāng)重要，尤其是在企業(yè)或者組織中，數(shù)據(jù)更是至關(guān)重要的組成部分。為了更好地管理和利用數(shù)據(jù)，數(shù)據(jù)庫誕生了。數(shù)據(jù)庫通常包括數(shù)據(jù)、數(shù)據(jù)定義、數(shù)據(jù)操縱和數(shù)據(jù)控制等幾個(gè)方面。而要想提高數(shù)據(jù)庫的效率和性能，就需要掌握expln的使用方法。

什么是expln？

在MySQL中，expln是一種可以分析SQL查詢語句的工具，可以根據(jù)查詢語句來生成一個(gè)執(zhí)行計(jì)劃，包括了查詢優(yōu)化器的選擇，數(shù)據(jù)的訪問方式等等，從而幫助我們找到SQL語句中出現(xiàn)性能問題的問題所在，從而對(duì)其進(jìn)行優(yōu)化。

expln的使用方法

expln的語法十分簡(jiǎn)單，就是在查詢語句的前面添加一個(gè)expln關(guān)鍵詞即可。例如下面是一個(gè)查詢語句：

SELECT * FROM user WHERE name = ‘a(chǎn)bc’;

那么使用expln就是將其改寫為：

EXPLN SELECT * FROM user WHERE name = ‘a(chǎn)bc’;

執(zhí)行這個(gè)語句之后，我們就可以得到這個(gè)查詢語句的執(zhí)行計(jì)劃。

執(zhí)行計(jì)劃中包含了許多重要的字段，下面我們來介紹一下：

id：指定了查詢中的每個(gè)表的唯一標(biāo)識(shí)符，可以用來確認(rèn)表的訪問順序。

select_type：查詢的類型，例如簡(jiǎn)單查詢、子查詢或者聯(lián)合查詢等等。

table：表名，該查詢的數(shù)據(jù)來自哪個(gè)表。

partitions：用于表示查詢中的表被分區(qū)的情況。

type：訪問表的方式，例如全表掃描、索引掃描等等。

possible_keys：表示用于此查詢的可用參數(shù)

key：表示鎖定來自相應(yīng)表的記錄的索引（如果有）

rows：表示MySQL執(zhí)行查詢以返回所需結(jié)果所需檢查的行數(shù)的估計(jì)值。

Extra：包含一些關(guān)于查詢的各種信息，例如使用了哪個(gè)索引、是否使用了臨時(shí)表等等。

根據(jù)上面的信息，我們可以發(fā)現(xiàn)，能夠從執(zhí)行計(jì)劃中獲得很多有用的信息。例如，如果查詢結(jié)果中表的訪問方式是全表掃描，那么很可能是因?yàn)樵摫頉]有被正確地索引。因此，我們需要針對(duì)索引進(jìn)行優(yōu)化，以便更快地訪問表。

除此之外，在查詢語句執(zhí)行過程中，expln還可以為我們分析不同的執(zhí)行方案，以及各種執(zhí)行方案下的IO和CPU等消耗情況等等，從而更精細(xì)地分析性能瓶頸。

Expln可以提供查詢語句執(zhí)行計(jì)劃的詳細(xì)信息，從而讓我們更好地了解查詢語句的性能和優(yōu)化方向。對(duì)于需要對(duì)數(shù)據(jù)庫性能進(jìn)行優(yōu)化的工程師來說，掌握expln的使用方法是一個(gè)不可或缺的技能。但是需要注意的是，不要過度使用expln，因?yàn)閳?zhí)行過程會(huì)影響數(shù)據(jù)庫的性能。

相關(guān)問題拓展閱讀：

• 數(shù)據(jù)庫索引的操作案例

數(shù)據(jù)庫索引的操作案例

最普通的情況，是為出現(xiàn)在where子句的字段建一個(gè)索引。為方便講述，先建立一個(gè)如下的含租表。

CREATE TABLE mytable(

idserial primary key,

category_id int not null default0,

user_id int not null default0,

adddate int not null default0

);

如果在查詢時(shí)常用類似以下的語句：

SELECT * FROM mytable WHERE category_id=1;

最直接的應(yīng)對(duì)之道，是為category_id建立一個(gè)簡(jiǎn)單的索引：

CREATE INDEX mytable_categoryid ON mytable (category_id);

OK.如果有不止一個(gè)選擇條件呢？例如：

SELECT * FROM mytable WHERE category_id=1 AND user_id=2;

之一反應(yīng)可能是，再給user_id建立一個(gè)索引。不好，這不是一個(gè)更佳的方法。可以建立多重的索引。

CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);

注意到在命名時(shí)的習(xí)慣了嗎？使用表名_字段1名_字段2名的方式。很快就會(huì)知道為什么這樣做了。

現(xiàn)在已經(jīng)為適當(dāng)?shù)淖侄谓⒘怂饕?，不過，還是有點(diǎn)不放心吧，可能會(huì)問，數(shù)據(jù)庫會(huì)真正用到這些索引嗎？測(cè)試一下就OK，談宏兆對(duì)于大多數(shù)的數(shù)據(jù)庫來說，這是很容易的，只要使用EXPLAIN命令：

EXPLAIN

SELECT * FROM mytable

WHERE category_id=1 AND user_id=2;

This is what Postgres 7.1 returns (exactlyasI expected)

NOTICE:QUERY PLAN:

Index Scan using mytable_categoryid_userid on

mytable(cost=0.00..2.02 rows=1 width=16)

EXPLAIN

以上是postgres的數(shù)據(jù)，可以看到該數(shù)據(jù)庫在查詢的時(shí)候使用了一個(gè)索引（一個(gè)好開始），而且它使用的是創(chuàng)建的第二個(gè)索引?？吹缴厦婷暮锰幜税?，馬上知道它使用適當(dāng)?shù)乃饕恕?/p>

接著，來個(gè)稍微復(fù)雜一點(diǎn)的，如果有個(gè)ORDERBY 子句呢？不管你信不信，大多數(shù)的數(shù)據(jù)庫在使用orderby的時(shí)候，都將會(huì)從索引中受益。

SELECT * FROM mytable

WHERE category_id=1 AND user_id=2

ORDER BY adddate DESC;

很簡(jiǎn)單，就像為where子句中的字段建立一個(gè)索引一樣，也為ORDER BY的子句中的字段建立一個(gè)索引：

CREATE INDEX mytable_categoryid_userid_adddate ON mytable (category_id,user_id,adddate);

注意:mytable_categoryid_userid_adddate將會(huì)被截短為mytable_categoryid_userid_addda

CREATE

EXPLAIN SELECT * FROM mytable

WHERE category_id=1 AND user_id=2

ORDER BY adddate DESC;

NOTICE:QUERY PLAN:

Sort(cost=2.03..2.03 rows=1 width=16)

->Index Scanusing mytable_categoryid_userid_addda

on mytable(cost=0.00..2.02 rows=1 width=16)

EXPLAIN

看看EXPLAIN的輸出，數(shù)據(jù)庫多做了一個(gè)沒有要求的排序，這下知道性能如何受損了吧，看來對(duì)于數(shù)據(jù)庫的自身運(yùn)作是有點(diǎn)過于樂觀了，那么，給數(shù)據(jù)庫多一點(diǎn)提絕碼示吧。

為了跳過排序這一步，并不需要其它另外的索引，只要將查詢語句稍微改一下。這里用的是postgres，將給該數(shù)據(jù)庫一個(gè)額外的提示–在ORDER BY語句中，加入where語句中的字段。這只是一個(gè)技術(shù)上的處理，并不是必須的，因?yàn)閷?shí)際上在另外兩個(gè)字段上，并不會(huì)有任何的排序操作，不過如果加入，postgres將會(huì)知道哪些是它應(yīng)該做的。

EXPLAIN SELECT * FROM mytable

WHERE category_id=1 AND user_id=2

ORDER BY category_id DESC,user_id DESC,adddate DESC;

NOTICE:QUERY PLAN:

Index Scan Backward using

mytable_categoryid_userid_addda on mytable(cost=0.00..2.02 rows=1 width=16)

EXPLAIN

現(xiàn)在使用料想的索引了，而且它還挺聰明，知道可以從索引后面開始讀，從而避免了任何的排序。

以上說得細(xì)了一點(diǎn)，不過如果數(shù)據(jù)庫非常巨大，并且每日的頁面請(qǐng)求達(dá)上百萬算，想會(huì)獲益良多的。不過，如果要做更為復(fù)雜的查詢呢，例如將多張表結(jié)合起來查詢，特別是where限制字句中的字段是來自不止一個(gè)表格時(shí)，應(yīng)該怎樣處理呢？通常都盡量避免這種做法，因?yàn)檫@樣數(shù)據(jù)庫要將各個(gè)表中的東西都結(jié)合起來，然后再排除那些不合適的行，搞不好開銷會(huì)很大。

如果不能避免，應(yīng)該查看每張要結(jié)合起來的表，并且使用以上的策略來建立索引，然后再用EXPLAIN命令驗(yàn)證一下是否使用了料想中的索引。如果是的話，就OK。不是的話，可能要建立臨時(shí)的表來將他們結(jié)合在一起，并且使用適當(dāng)?shù)乃饕?/p>

要注意的是，建立太多的索引將會(huì)影響更新和插入的速度，因?yàn)樗枰瑯痈旅總€(gè)索引文件。對(duì)于一個(gè)經(jīng)常需要更新和插入的表格，就沒有必要為一個(gè)很少使用的where字句單獨(dú)建立索引了，對(duì)于比較小的表，排序的開銷不會(huì)很大，也沒有必要建立另外的索引。

以上介紹的只是一些十分基本的東西，其實(shí)里面的學(xué)問也不少，單憑EXPLAIN是不能判定該方法是否就是更優(yōu)化的，每個(gè)數(shù)據(jù)庫都有自己的一些優(yōu)化器，雖然可能還不太完善，但是它們都會(huì)在查詢時(shí)對(duì)比過哪種方式較快，在某些情況下，建立索引的話也未必會(huì)快，例如索引放在一個(gè)不連續(xù)的存儲(chǔ)空間時(shí)，這會(huì)增加讀磁盤的負(fù)擔(dān)，因此，哪個(gè)是更優(yōu)，應(yīng)該通過實(shí)際的使用環(huán)境來檢驗(yàn)。

在剛開始的時(shí)候，如果表不大，沒有必要作索引，意見是在需要的時(shí)候才作索引，也可用一些命令來優(yōu)化表，例如MySQL可用OPTIMIZETABLE。

數(shù)據(jù)庫explain的用法的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于數(shù)據(jù)庫explain的用法,深入了解數(shù)據(jù)庫：掌握explain使用方法,數(shù)據(jù)庫索引的操作案例的信息別忘了在本站進(jìn)行查找喔。

創(chuàng)新互聯(lián)成都網(wǎng)站建設(shè)公司提供專業(yè)的建站服務(wù)，為您量身定制，歡迎來電（028-86922220）為您打造專屬于企業(yè)本身的網(wǎng)絡(luò)品牌形象。
成都創(chuàng)新互聯(lián)品牌官網(wǎng)提供專業(yè)的網(wǎng)站建設(shè)、設(shè)計(jì)、制作等服務(wù)，是一家以網(wǎng)站建設(shè)為主要業(yè)務(wù)的公司，在網(wǎng)站建設(shè)、設(shè)計(jì)和制作領(lǐng)域具有豐富的經(jīng)驗(yàn)。

網(wǎng)站標(biāo)題：深入了解數(shù)據(jù)庫：掌握explain使用方法(數(shù)據(jù)庫explain的用法)
文章位置：http://uogjgqi.cn/article/dpgepgg.html