国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

為mysql數據庫建立索引

Astrian / 3143人閱讀

摘要:最普通的情況,是為出現在子句的字段建一個索引。綜上所述,在如何為數據庫建立恰當的索引方面,你應該有一些基本的概念了。

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

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
);

很簡單吧,不過對于要說明這個問題,已經足夠了。如果你在查詢時常用類似以下的語句:

SELECT * FROM mytable WHERE category_id=1; 

最直接的應對之道,是為category_id建立一個簡單的索引:

CREATE INDEX mytable_categoryid 
ON mytable (category_id);

OK,搞定?先別高興,如果你有不止一個選擇條件呢?例如:

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

你的第一反應可能是,再給user_id建立一個索引。不好,這不是一個最佳的方法。你可以建立多重的索引。

CREATE INDEX mytable_categoryid_userid ON mytable (category_id,user_id);

注意到我在命名時的習慣了嗎?我使用"表名_字段1名_字段2名"的方式。你很快就會知道我為什么這樣做了。

現在你已經為適當的字段建立了索引,不過,還是有點不放心吧,你可能會問,數據庫會真正用到這些索引嗎?測試一下就OK,對于大多數的數據庫來說,這是很容易的,只要使用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的數據,可以看到該數據庫在查詢的時候使用了一個索引(一個好開始),而且它使用的是我創建的第二個索引??吹轿疑厦婷暮锰幜税?,你馬上知道它使用適當的索引了。

接著,來個稍微復雜一點的,如果有個ORDER BY字句呢?不管你信不信,大多數的數據庫在使用order by的時候,都將會從索引中受益。

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

有點迷惑了吧?很簡單,就象為where字句中的字段建立一個索引一樣,也為ORDER BY的字句中的字段建立一個索引:

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

注意: "mytable_categoryid_userid_affffdate" 將會被截短為

"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的輸出,好象有點恐怖啊,數據庫多做了一個我們沒有要求的排序,這下知道性能如何受損了吧,看來我們對于數據庫的自身運作是有點過于樂觀了,那么,給數據庫多一點提示吧。

為了跳過排序這一步,我們并不需要其它另外的索引,只要將查詢語句稍微改一下。這里用的是postgres,我們將給該數據庫一個額外的提示--在ORDER BY語句中,加入where語句中的字段。這只是一個技術上的處理,并不是必須的,因為實際上在另外兩個字段上,并不會有任何的排序操作,不過如果加入,postgres將會知道哪些是它應該做的。

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

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

以上說得細了一點,不過如果你的數據庫非常巨大,并且每日的頁面請求達上百萬算,我想你會獲益良多的。不過,如果你要做更為復雜的查詢呢,例如將多張表結合起來查詢,特別是where限制字句中的字段是來自不止一個表格時,應該怎樣處理呢?我通常都盡量避免這種做法,因為這樣數據庫要將各個表中的東西都結合起來,然后再排除那些不合適的行,搞不好開銷會很大。

如果不能避免,你應該查看每張要結合起來的表,并且使用以上的策略來建立索引,然后再用EXPLAIN命令驗證一下是否使用了你料想中的索引。如果是的話,就OK。不是的話,你可能要建立臨時的表來將他們結合在一起,并且使用適當的索引。

要注意的是,建立太多的索引將會影響更新和插入的速度,因為它需要同樣更新每個索引文件。對于一個經常需要更新和插入的表格,就沒有必要為一個很少使用的where字句多帶帶建立索引了,對于比較小的表,排序的開銷不會很大,也沒有必要建立另外的索引。

以上介紹的只是一些十分基本的東西,其實里面的學問也不少,單憑EXPLAIN我們是不能判定該方法是否就是最優化的,每個數據庫都有自己的一些優化器,雖然可能還不太完善,但是它們都會在查詢時對比過哪種方式較快,在某些情況下,建立索引的話也未必會快,例如索引放在一個不連續的存儲空間時,這會增加讀磁盤的負擔,因此,哪個是最優,應該通過實際的使用環境來檢驗。

在剛開始的時候,如果表不大,沒有必要作索引,我的意見是在需要的時候才作索引,也可用一些命令來優化表,例如MySQL可用"OPTIMIZE TABLE"。

綜上所述,在如何為數據庫建立恰當的索引方面,你應該有一些基本的概念了。

轉自:http://www.cnblogs.com/cy163/...

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/70338.html

相關文章

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

    摘要:本期圖解我們為大家解析一下是如何構建的。因此建立的第一關就是只為頻繁使用的索引樹建立。關卡該索引樹上的某個檢索條件要被經常使用顯而易見,如果我們為了一個很少出現的檢索條件建立,肯定是入不敷出的。Adaptive Hash Index(以下簡稱 AHI)估計是 MySQL 的各大特性中,大家都知道名字但最說不清原理的一個特性。本期圖解我們為大家解析一下 AHI 是如何構建的。首先我們思考一下 ...

    Tecode 評論0 收藏0
  • 據庫索引

    摘要:通過增加額外的寫操作和存儲空間來維護數據庫索引,可以提高從數據庫中讀取數據的速度。數據庫索引的實現常見的數據庫索引實現有平衡樹樹樹哈希樹,樹參考,中的索引數據庫支持多種索引類型,如索引,哈希索引,全文索引等等。 數據庫索引簡介 數據庫索引的定義 數據庫索引是一種數據結構。通過增加額外的寫操作和存儲空間來維護數據庫索引,可以提高從數據庫中讀取數據的速度。通過索引,不需要搜索數據庫的每一條...

    Towers 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<