元高度就是oracle
資料庫中幫助資料庫管理員來做好這個工作的工具。什麼叫做二元高度呢
?說實話筆者也不了解這個名詞具體代表的含義。只知道索引二元高高度對把rowid
返回給使用者
程序時所要求的i/0
數量起到非常關鍵的作用。資料庫管理員只要了解這個即可，而不需要花費很長的時間去搞明白什麼叫做二元高度。在oracle
資料庫中，系統檢視
sys.dba_indexes
就儲存在索引的二元高度資訊。如下圖所示的
sql語句，可以查詢處索引的二元高度的值。
如上圖所示，欄位blevel
表示二元高度
;index_name
則表示索引的名稱。一般來說，二元高度越低越好(
最低為0)
。作為資料庫管理員，就是需要相方設法讓這個二元高度的值變為0
。雖然這個目標看起來比較簡單，但是實現起來卻有相當大的困難。
一、二元高度對索引的影響。
為了說明二元高度對索引的影響，筆者舉乙個例子為大家說明。假設現在有乙個索引，其二元高度為3
。此時如果使用者需要利用這個索引來查詢資料的話，則此時同時將會有
4個塊被讀取，其中
3個來自索引，乙個來自表。隨著索引二元高度的值的增加，整個檢索資料所要求的
i/o數量也會隨之增加。因為二元高度增加乙個級別都會增加乙個額外的讀取快。而且通常情況下由於這些塊布能夠按照順序讀取，他們都會要求乙個獨立的
i/o操作。所以在這個二元高度的值越大，其
i/o爭用的現象也可能會越頻繁。此時其資料庫索引的效能也就會越低。
二、如何來查詢二元高度的值?
通常情況下，資料庫管理員可以對索引或者表進行分析從而得到索引的二元高度。不過這個分析比較複雜。筆者是建議各位資料庫管理員直接查詢資料檢視sys.dba_indexes
，來獲得系統當前索引的二元高度值。既然資料庫中已經有類似的值，那麼就沒有必要浪費時間在去手工分析這些值了。以前筆者在給跟一些資料庫管理員溝通的時候，他們也詢問過筆者，這個二元高度的值是如何計算出來的。筆者給他們解釋了好半天，他們仍然搞不明白。其實這也怪不得他們，因為筆者對這個計算分析的過程也是一知半解。所以不知道這個二元高度的值怎麼計算出來的，沒有關係。只要知道該從哪個地方去查詢這個值即可。
三、哪些因素會影響到這個值?
在對索引進行優化的時候，就是要想盡一切辦法，把這個值降低到最低。而要實現降低這個二元高度的值的目標，則資料庫管理員就必須先了解哪些因素跟這個值有關。如此的話，資料庫管理員才能夠對症下藥，降低二元高度的值，提高索引的效能。
1、刪除操作。有時候資料庫管理員可能會發現他們剛完成資料的匯入工作，就會發現資料庫的效能有所下降。而此時查詢這個二元高度的值，則會發現這個值非常的大。照理來說，才剛完成資料的匯入功能，還沒有進行其它的一些業務操作，這個值不應該很大呀。那這是怎麼一回事情呢
?其實，這主要是因為大量的刪除操作所造成的。原來在匯入資料的時候，可能會發現某些資料匯入有問題。故有些資料庫管理員會利用
delete
語句清除倒入到資料庫中的記錄。此時資料庫管理員就需要注意，索引上如果有大量被刪除的行，則它對應的二元高度的值也就會逐漸增加。遇到這種情況時，資料庫管理員可以嘗試著重建索引。通常情況下，如果二元高度的值比較大確實是因為刪除操作所引起的，那麼通過這個重建索引的工作後，基本上可以把這個二元高度的值降下去。筆者建議，如果乙個索引中被刪除掉記錄接近於全部記錄的30%
左右，此時資料庫管理員就需要採取重建索引的作業，用於降低二元高度以及在一次
i/o過程中所讀取的空閒時間。
2、資料塊尺寸。通常情況下，資料庫塊尺寸與二元高度的值是成反比的。資料塊尺寸越大，則索引的二元高度就越低。資料塊大小是表空間管理中的乙個屬性。通常情況下，資料庫管理員在建立表空間的時候，往往採用其預設的塊大小，而不會改變其大小。system與sysaux
是系統表空間，他們的資料塊大小往往是在表空間建立時的初始化引數定義的。一般情況下不同的表空間可以由不同的塊大小，以對應不同的表空間對於效能的不同要求。不過總的來說，這個資料庫塊也不是說分的越細越好。這會增加資料庫維護的難度。在
oracle
資料庫中，對此也做了一定的限制。如正常情況下，這個資料庫最多可以設定五個不同的資料塊大小。
`資料庫
`是以資料塊為單位分配和使用磁碟空間，乙個資料塊是磁碟空間中固定個數的位元組，位於磁碟空間管理的最底層。通常情況下，乙個資料塊的大小從
8kb到
32kb
之間。並不是說，其可以取到
8kb到
32kb
之間的任何值，其還必須滿足必須是儲存器裝置的物理塊大小的乙個倍數。如資料庫儲存器裝置的儲存快大小為
8kb的話，則這個資料塊的大小就可以為8、
16、24、
32kb
中的任何乙個值。如果不考慮其他因素，在建立資料表時設定比較大的資料塊，可以降低二元高度的值，可以產生比較淺的
b樹，可以產生比較佳的效能。一般來說，如果資料庫管理員認為資料庫比較複雜，所涉及的應用比較大的話，在可以把資料塊設定的比較大一點，如
24kb
，甚至32kb
。這裡需要注意的是，如果資料庫系統用來做資料倉儲，則最好把這個數塊設定為
32kb
。而對於其他用途的資料庫，則需要根據資料庫應用的負責程度來進行合適的設定。如果要說把資料庫塊大小設定為多少合適，要定乙個具體的值，恐怕沒有人可以輕易下這個結論。資料庫管理員需要根據企業資料庫的實際應用，來確定乙個合適的值。而這就跟資料庫管理員的經驗掛鉤了。豐富的資料庫管理經驗，可以幫助管理員來設定乙個合適的資料塊。如果只資料庫只用來學習用的話，那麼在建立表空間時可以忽略這個引數，直接採用預設的資料塊大小即可。而如果資料庫用來當作生產用資料庫時，則對此資料庫管理員就需要慎重考慮。可以結合這個索引相關的二元高度引數來判斷當前的資料庫塊大小是否合適。
3、二元高度的值還會隨著索引列中的非null
數量以及索引列中值的範圍狹窄程度而變化。一般來說，索引列中非null
的數量越多
(即空字段餘越少
)則其二元高度的值越低。或者說，索引列中的值越靠近，即範圍比較小，則其二元高度的值也就越低。為此，這就提醒資料庫管理員在設計索引的時候，最好能夠把索引字段設定為非空。如此的話，就可以降低索引的二元高度，以提高索引的效能。如筆者在索引設計時，往往把索引字段設定為非空。而使用者在實際應用的過程中，如果這個索引字段暫時不需要輸入內容(
如可能暫時無法取得這個值，需要在後續補入
)，此時系統就會採用乙個預設值(如
null)
，來表示這個欄位的內容暫時為空。不過在資料庫儲存的時候，已經有具體的內容了。如此即可以滿足索引列非空的需要，使用者在日後也可以修改這個資訊
;同時又降低了二元高度的值，提高了資料庫索引的效能。一舉多得，資料庫管理員可以嘗試。另外，把索引列的值在滿足應用的前提下，限制在乙個比較小的範圍之內，也可以降低這個二元高度的值。
如何判斷應用系統效能好不好？
如果有人問，這個系統的效能到底好不好？有什麼指標，能夠說明系統的效能？且看老楊的這篇文章 如何判斷乙個應用系統效能好不好？在建設專案系統投入生產應用前，往往會對系統做個效能壓測，一是為了驗證系統的在設定的不同併發數 使用者數和對應業務場景下的負載能力，是否符合系統最初的設定目標，二是做到心中有數，知...
如何寫出效能好的sql
開發人員是很少注意sql對資料庫效能影響的重要性的，大多程式設計師都會認為sql是比較簡單的，需要的時候查查手冊就可以了，很少有深究的。這樣的觀念對大型系統的開發是致命的，需要糾正這樣的觀念。造成這樣的原因，可能有如下幾種 1，對資料庫效能的研究，成果不是顯而易見，對程式設計師的成就感激勵不足，因為...
mysql高效能索引 mysql高效能索引（ ）
在開發中，我們知道大多數應用的瓶頸在於sql語句的執行時耗，在這裡並不討論sql語句的安全，僅僅討論高效能sql語句，而與高效能sql語句緊密相連的就是傳說中的 索引。索引 一種工作在儲存引擎端的用於快速找到記錄的一種資料結構。mysql使用索引的方式是 先找到索引的值，再根據索引的值找到資料行。索...