成人无码视频,亚洲精品久久久久av无码,午夜精品久久久久久毛片,亚洲 中文字幕 日韩 无码

資訊專欄INFORMATION COLUMN

為mysql數(shù)據(jù)庫(kù)建立索引

Astrian / 3188人閱讀

摘要:最普通的情況,是為出現(xiàn)在子句的字段建一個(gè)索引。綜上所述,在如何為數(shù)據(jù)庫(kù)建立恰當(dāng)?shù)乃饕矫?,你?yīng)該有一些基本的概念了。

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

Code代碼如下:
CREATE TABLE mytable (
 id serial primary key,
 category_id int not null default 0,
 user_id int not null default 0,
 affffdate int not null default 0
);

很簡(jiǎn)單吧,不過(guò)對(duì)于要說(shuō)明這個(gè)問(wèn)題,已經(jīng)足夠了。如果你在查詢時(shí)常用類(lèi)似以下的語(yǔ)句:

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ù)淖侄谓⒘怂饕?,不過(guò),還是有點(diǎn)不放心吧,你可能會(huì)問(wèn),數(shù)據(jù)庫(kù)會(huì)真正用到這些索引嗎?測(cè)試一下就OK,對(duì)于大多數(shù)的數(shù)據(jù)庫(kù)來(lái)說(shuō),這是很容易的,只要使用EXPLAIN命令:

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

This is what Postgres 7.1 returns (exactly as I 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ù)庫(kù)在查詢的時(shí)候使用了一個(gè)索引(一個(gè)好開(kāi)始),而且它使用的是我創(chuàng)建的第二個(gè)索引。看到我上面命名的好處了吧,你馬上知道它使用適當(dāng)?shù)乃饕恕?/p>

接著,來(lái)個(gè)稍微復(fù)雜一點(diǎn)的,如果有個(gè)ORDER BY字句呢?不管你信不信,大多數(shù)的數(shù)據(jù)庫(kù)在使用order by的時(shí)候,都將會(huì)從索引中受益。

SELECT * FROM mytable 
WHERE category_id=1 AND user_id=2
ORDER BY affffdate DESC;

有點(diǎn)迷惑了吧?很簡(jiǎn)單,就象為where字句中的字段建立一個(gè)索引一樣,也為ORDER BY的字句中的字段建立一個(gè)索引:

CREATE INDEX mytable_categoryid_userid_affffdate
ON mytable (category_id,user_id,affffdate);

注意: "mytable_categoryid_userid_affffdate" 將會(huì)被截短為

"mytable_categoryid_userid_affffda"

CREATE

EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY affffdate DESC;

NOTICE: QUERY PLAN:

Sort (cost=2.03..2.03 rows=1 width=16)
-> Index Scan using mytable_categoryid_userid_affffda 
on mytable (cost=0.00..2.02 rows=1 width=16)

EXPLAIN

看看EXPLAIN的輸出,好象有點(diǎn)恐怖啊,數(shù)據(jù)庫(kù)多做了一個(gè)我們沒(méi)有要求的排序,這下知道性能如何受損了吧,看來(lái)我們對(duì)于數(shù)據(jù)庫(kù)的自身運(yùn)作是有點(diǎn)過(guò)于樂(lè)觀了,那么,給數(shù)據(jù)庫(kù)多一點(diǎn)提示吧。

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

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

  ORDER BY category_id DESC,user_id DESC,affffdate DESC;

NOTICE: QUERY PLAN:

Index Scan Backward using 

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

EXPLAIN

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

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

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

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

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

在剛開(kāi)始的時(shí)候,如果表不大,沒(méi)有必要作索引,我的意見(jiàn)是在需要的時(shí)候才作索引,也可用一些命令來(lái)優(yōu)化表,例如MySQL可用"OPTIMIZE TABLE"。

綜上所述,在如何為數(shù)據(jù)庫(kù)建立恰當(dāng)?shù)乃饕矫妫銘?yīng)該有一些基本的概念了。

轉(zhuǎn)自:http://www.cnblogs.com/cy163/...

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://m.hztianpu.com/yun/70338.html

相關(guān)文章

  • 圖解MySQL | [原理解析] Adaptive Hash Index 是如何建立

    摘要:本期圖解我們?yōu)榇蠹医馕鲆幌率侨绾螛?gòu)建的。因此建立的第一關(guān)就是只為頻繁使用的索引樹(shù)建立。關(guān)卡該索引樹(shù)上的某個(gè)檢索條件要被經(jīng)常使用顯而易見(jiàn),如果我們?yōu)榱艘粋€(gè)很少出現(xiàn)的檢索條件建立,肯定是入不敷出的。Adaptive Hash Index(以下簡(jiǎn)稱 AHI)估計(jì)是 MySQL 的各大特性中,大家都知道名字但最說(shuō)不清原理的一個(gè)特性。本期圖解我們?yōu)榇蠹医馕鲆幌?AHI 是如何構(gòu)建的。首先我們思考一下 ...

    Tecode 評(píng)論0 收藏0
  • 數(shù)據(jù)庫(kù)索引

    摘要:通過(guò)增加額外的寫(xiě)操作和存儲(chǔ)空間來(lái)維護(hù)數(shù)據(jù)庫(kù)索引,可以提高從數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)的速度。數(shù)據(jù)庫(kù)索引的實(shí)現(xiàn)常見(jiàn)的數(shù)據(jù)庫(kù)索引實(shí)現(xiàn)有平衡樹(shù)樹(shù)樹(shù)哈希樹(shù),樹(shù)參考,中的索引數(shù)據(jù)庫(kù)支持多種索引類(lèi)型,如索引,哈希索引,全文索引等等。 數(shù)據(jù)庫(kù)索引簡(jiǎn)介 數(shù)據(jù)庫(kù)索引的定義 數(shù)據(jù)庫(kù)索引是一種數(shù)據(jù)結(jié)構(gòu)。通過(guò)增加額外的寫(xiě)操作和存儲(chǔ)空間來(lái)維護(hù)數(shù)據(jù)庫(kù)索引,可以提高從數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)的速度。通過(guò)索引,不需要搜索數(shù)據(jù)庫(kù)的每一條...

    Towers 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

閱讀需要支付1元查看
<