反正死鎖問(wèn)題你看到剛才那個(gè)結(jié)果就夠了,就是他已經(jīng)把死鎖問(wèn)題給你解決了,畢竟你只要出現(xiàn)死鎖,畢竟有一方用戶就彈出來(lái)了,退出了,直接就彈出來(lái)了,這是ORACLE系統(tǒng)自己去解決了,咱們繼續(xù)往下看

下面咱們要講一個(gè)概念,這個(gè)概念其實(shí)也是一樣的,除了死鎖這個(gè)事,咱們講索引這個(gè)事,那索引我還是以O(shè)RACLE為例,MYSQL其實(shí)都是一樣的,其實(shí)都是想通的,其實(shí)上面的這些也都是想通的,ORACLE有自己的處理方案,MYSQL有自己的處理方案而已,然后現(xiàn)在就是索引,一般都是Balanced Tree,就是B樹(shù)索引,Balance Tree,B樹(shù)索引,平衡樹(shù)索引,一般來(lái)講這個(gè)結(jié)構(gòu)就是這樣,首先它分無(wú)數(shù)個(gè)葉塊,一般來(lái)講我就講成葉塊,就是根節(jié)點(diǎn)塊,比如說(shuō)你這個(gè)索引是從0開(kāi)始,0到500,然后到1000,咱們就分為B1,B2,B3,然后下面這塊又分支了,B1這塊一定是0到小于500,就是499,然后B2這塊就是500到999,然后B3就是1000+,這塊就是最上層的,然后分一塊,這塊就兩塊,三塊,然后再往下,他又區(qū)分,從0到200又給我分一個(gè)塊,然后從200到400又給我分一個(gè)塊,一直到399,然后到400一直到499,再分一個(gè)塊,同理500到699,分一個(gè)塊,然后700到799分一個(gè)塊,就是分無(wú)數(shù)個(gè)塊,把一個(gè)很大范圍的分成無(wú)數(shù)個(gè)小葉塊,那么我查詢的時(shí)候這個(gè)小東西,相當(dāng)于去做定位了,比如我想去查第450個(gè)塊,一下子我就檢索到了這塊了,這兩塊我都可以不查了,從這里我又往下走,又很快找到這塊了,450肯定包含在這里面,然后在這里又直接把450這條記錄直接就找到了,一跳,兩跳,三跳,四跳就直接找到了,就是索引內(nèi)部的設(shè)計(jì)原理,當(dāng)然咱們的索引,咱們建一個(gè)表,建完索引之后,他肯定有另外的一塊空間,做一個(gè)維護(hù)的Balanced Tree,所以你一般給一個(gè)表建一個(gè)索引,都會(huì)犧牲你的空間的,你表里存數(shù)據(jù)犧牲空間,建索引也會(huì)犧牲空間,它會(huì)維護(hù)Balance Tree里面的結(jié)構(gòu),他肯定是需要去維護(hù)的,所以我們?nèi)ゲ樵兊臅r(shí)候,會(huì)定位的很快,維護(hù)的這塊空間,這沒(méi)問(wèn)題吧,這個(gè)東西是一個(gè)很簡(jiǎn)單的一件事,然后咱們繼續(xù)往下看,B樹(shù)索引其實(shí)還有其他的索引,什么位圖索引啊,咱們其實(shí)就是研究B樹(shù)就行了其他的無(wú)所謂了

SQL的概念,就是咱們?nèi)?yōu)化SQL,優(yōu)化SQL語(yǔ)句,無(wú)非就是4種方案嗎,在這里寫(xiě)了1. 建索引2. 建分區(qū)3. 物化視圖4. 并行查詢就這四塊

索引的概念這塊可以看一下

分為兩大類在ORACLE里面1. Balance Tree平衡樹(shù)索引2. 位圖索引,在離散度非常低的時(shí)候可以使用位圖索引,你可以上網(wǎng)去搜搜位圖索引,這個(gè)咱們開(kāi)發(fā)來(lái)說(shuō)還是用的不多的,除非你用到適合位圖索引的需求,一般都是屬于Balance Tree,是B樹(shù)索引 然后往下看索引的說(shuō)明和目的

索引的說(shuō)明,基本上就是說(shuō),我只是針對(duì)于ORACLE,索引是和表相關(guān)聯(lián)的一個(gè)可選結(jié)構(gòu),也就是你可以建也可以不建,在邏輯上和物理上都有獨(dú)立于表的數(shù)據(jù),索引能優(yōu)化查詢,這個(gè)說(shuō)的是毋庸置疑的,但不能優(yōu)化DML操作,什么意思呢,就是這個(gè)東西就是兩者之間永遠(yuǎn)是不可調(diào)和的事情,就好像你設(shè)計(jì)一張表,你建了一個(gè)索引,那么你去insert的時(shí)候,你除了把這條記錄插入到表里以外,你還得把這條記錄對(duì)應(yīng)的索引給進(jìn)行維護(hù)一下,這東西是永遠(yuǎn)都不可調(diào)和的,建兩個(gè)索引你就得多維護(hù)一塊,你建三個(gè)索引你就還得再多維護(hù)一塊空間,那就是索引建多了,你進(jìn)行寫(xiě)操作,那效率性能上,IO性能上就會(huì)降低,但是你的查詢效率就會(huì)變快了,這是肯定的,你永遠(yuǎn)都沒(méi)法去權(quán)衡,我們其實(shí)軟件開(kāi)發(fā),大多數(shù)最多的情況下,其實(shí)都是兩種方案取一個(gè)中間值,根據(jù)你自己的業(yè)務(wù)去做一個(gè)平衡,咱們軟件在做設(shè)計(jì)的時(shí)候,用的最多的是用空間換時(shí)間,就是為了提高性能,犧牲一些空間,然后去換取時(shí)間,包括你做這個(gè)中間庫(kù),做這個(gè)緩存表,包括我們?nèi)プ鲆粋€(gè)Lunece,Sorl,或者是ES,這些東西,大體上都是用空間換時(shí)間,很多設(shè)計(jì)其實(shí)都是從這個(gè)角度去考慮的,不同的維度怎么去做,后期再一點(diǎn)一點(diǎn)去講吧,這個(gè)是ORACLE里面的一個(gè)概念了,如果SQL語(yǔ)句僅訪問(wèn)被索引的列,就是你訪問(wèn)的是索引的列比如ID就是索引,你只是查一下ID,那數(shù)據(jù)庫(kù)僅從索引中讀取數(shù)據(jù),而不讀取表,如果你只訪問(wèn)索引列之外,還訪問(wèn)列其他的數(shù)據(jù),你要查一條記錄的話,那他這個(gè)時(shí)候會(huì)根據(jù)rowid,來(lái)查找對(duì)應(yīng)的行,ORACLE里面有rowid的概念,除了有rownum隱式的行號(hào)之外,還有rowid這個(gè)東西,這個(gè)東西其實(shí)很好找的,我還是拿emp1吧,SELECT ROWID FROM EMP1,其實(shí)咱們的ORACLE表里有這么一行,這一行就是ROWID,其實(shí)他就通過(guò)ROWID去檢索哪個(gè)位置

咱們繼續(xù)往下走,數(shù)據(jù)庫(kù)會(huì)使用rowid來(lái)查詢表中的行,通常怎么怎么說(shuō),這個(gè)沒(méi)什么可說(shuō)的了,索引的目的是為了干什么,主要是為了減少IO,其實(shí)所有的東西都是為了減少IO,查詢的效率,讀寫(xiě),這樣才可以體現(xiàn)索引的效率,后面有一些建索引的規(guī)則,1. 大表,一個(gè)大表1000萬(wàn)條數(shù)據(jù),你要返回5%的記錄,你就要考慮建索引了2. 經(jīng)常使用where字句查詢的3. 離散度很高的列4. 更新代價(jià)比較低的,不是頻繁更新的,頻繁更新的你建完索引之后,你的頻繁的去維護(hù),這個(gè)東西很麻煩,浪費(fèi)性能5. 還有and和or效率高,邏輯and6. 查看索引在那一列,這個(gè)東西其實(shí)很簡(jiǎn)單,除了寫(xiě)存儲(chǔ)過(guò)程的時(shí)候,用SQL Window,正常情況我都用Command Window,這個(gè)東西你要查在什么地方,有這個(gè)索引,還有具體在哪一列,可以用這種SQL

基本上就是我當(dāng)前scott用戶,EMP這張表里面,EMPNO會(huì)是一個(gè)索引列,包括DEPT表里的DEPTNO是一個(gè)索引列,包括其他的表里都有索引,都能看到,通過(guò)一個(gè)查詢就能看到

其他的再往下看,索引的使用

ORACLE里面一般分7種索引:1. 正常我們一般使用唯一索引,你主鍵會(huì)unique index,create unique index emp_idx on emp1(empno)2. 一般索引,create index empno_idx on emp1(empno),這個(gè)語(yǔ)句就非常簡(jiǎn)單了,create index,給索引取個(gè)名,隨便起個(gè)名字,但是一般要見(jiàn)名知意,你叫empno_idx一看我就知道是emp表中的empno的字段它是一個(gè)索引,on是這個(gè)索引建在哪個(gè)表上,建在emp1這個(gè)表上,然后建在emp1這個(gè)表哪一列上,就是這塊有個(gè)大括號(hào),建在empno這個(gè)列上,這個(gè)語(yǔ)句其實(shí)是你要記住的,3. 組合索引像其他的沒(méi)有特殊需求,我一直用ORACLE這么多年,這些都沒(méi)怎么用過(guò),組合索引,也就是聯(lián)合索引,這個(gè)有的時(shí)候還用一點(diǎn),我一張表里兩個(gè)字段, create index job_deptno_idx on emp1(job,deptno);做這個(gè)索引4. reverse反向索引5. 函數(shù)索引6. 壓縮索引7. 升序降序索引,這個(gè)用的都很少

索引的一些問(wèn)題:就是它有一個(gè)索引碎片的問(wèn)題,應(yīng)該是一個(gè)很經(jīng)典的一個(gè)案例,ORACLE其實(shí)是可以解決索引碎片的問(wèn)題,我不知道MYSQL能不能解決,你們有用過(guò)MYSQL的嗎,那你可能都不知道索引碎片的概念,在這里我簡(jiǎn)單的說(shuō)一下,舉個(gè)例子,比如說(shuō)你數(shù)據(jù)庫(kù)里有一張表,這個(gè)系統(tǒng)上線了好久了,比如說(shuō)上線了幾年了,可能最初建索引維護(hù)都還好,你上線幾年了,這張表被頻繁的被update,delete,都會(huì)insert操作,這個(gè)時(shí)候你這個(gè)索引會(huì)干什么啊,這塊維護(hù)的區(qū)域就會(huì)不斷地去更新啊,修改啊,刪除啊等等,等等這種操作,那么你必然會(huì)對(duì)著操作產(chǎn)生一個(gè)碎片的問(wèn)題,就是你這張表頻繁的去insert,頻繁的去update,比如你這個(gè)id是一個(gè)索引列,之前是1,現(xiàn)在一下子給他改成3了,這相當(dāng)于你改索引列了,或者你把它delete了,你把ID這條記錄給delete了,你這個(gè)索引維護(hù)的時(shí)候是不是需要重新維護(hù)一下,包括insert,等等一些操作的時(shí)候,你這個(gè)索引碎片就會(huì)越來(lái)越大,當(dāng)然是上線很久了,可能最開(kāi)始的時(shí)候,表剛建出來(lái)的時(shí)候,可能1000萬(wàn)條數(shù)據(jù),你要走索引查一條數(shù)據(jù)的時(shí)候,可能一兩秒鐘你就直接檢索出來(lái)你想要的數(shù)據(jù),那么兩三年之后,頻繁的刪除,修改,刪除,產(chǎn)生索引碎片的問(wèn)題,那你這個(gè)時(shí)候又執(zhí)行相同語(yǔ)句的時(shí)候,你查詢出來(lái)的效率可能就不是一兩秒了,三四秒,七八秒都會(huì),逐漸的變慢,這個(gè)就是索引碎片的問(wèn)題產(chǎn)生的,這個(gè)問(wèn)題怎么去解決呢,其實(shí)在ORACLE里面是可以去解決的,我這里又一個(gè)描述,就是對(duì)于基表,原始表做DML操作,會(huì)導(dǎo)致索引塊自動(dòng)的更改操作,因?yàn)槟阕鯠ML操作,尤其是基表的DELETE操作,就是刪除索引列,刪除索引字段,刪除這個(gè)數(shù)據(jù),會(huì)引起index表,相當(dāng)于我們的emp表,他的emp表里有一個(gè)id,id肯定有一個(gè)index表,index表就是維護(hù)id的,可能這是一個(gè)index表,會(huì)導(dǎo)致index表的index_entries,邏輯刪除,然后注意只有一個(gè)索引塊,全部的index_entry被刪除了,才會(huì)把這個(gè)索引刪除了,索引對(duì)于基表的delete,就會(huì)產(chǎn)生索引碎片的問(wèn)題,只有當(dāng)一個(gè)索引塊全部index_entry全部都被刪除了,才會(huì)把這個(gè)索引塊刪除,就我這句話的意思,這塊已經(jīng)明白了,舉個(gè)例子,這個(gè)就是我們的索引塊,你看這塊,這塊有0這個(gè)位置,后面就是29了,維護(hù)的索引可能就是28個(gè),0一直到28,這個(gè)什么概念呢,索引塊是有大小的,你比如我現(xiàn)在,我把數(shù)據(jù)庫(kù)里面第一條記錄,給他刪掉了,那就相當(dāng)于他沒(méi)有第0個(gè)了,再刪再刪刪了特別多了,那可能是從第一條到第28條,整個(gè)索引塊可能就是,塊的大小肯定是不會(huì)變的,原先存的28個(gè)索引,整個(gè)這個(gè)塊空間,其實(shí)就沒(méi)啥用了,他說(shuō)的是什么意思呢,就是很浪費(fèi)空間嗎,存28個(gè)id的維護(hù),現(xiàn)在可能就存1個(gè),頻繁的去修改和刪除,做一個(gè)delete操作,索引給破壞了,這個(gè)時(shí)候,可能就沒(méi)啥用了,你索引再加上相同數(shù)據(jù)的時(shí)候,你得從新去建立塊,然后再去維護(hù),問(wèn)題是索引的物理的結(jié)構(gòu),會(huì)膨脹,你只有把index_entry全部都刪除了,從1到28里所有的數(shù)據(jù),你都給他刪除了以后,你才會(huì)把索引塊刪除,會(huì)有這個(gè)問(wèn)題,會(huì)產(chǎn)生一個(gè)索引碎片的問(wèn)題,導(dǎo)致咱們性能下降 在ORACLE里面沒(méi)有很清晰的給出索引碎片的量化標(biāo)準(zhǔn),然后ORACLE建立通過(guò)一個(gè)手段來(lái)解決索引碎片的問(wèn)題,如果你自行去解決的話,你可以去查看一個(gè)視圖,叫index_status視圖,里面可能會(huì)有一個(gè)索引碎片的一個(gè)整理,一個(gè)參考,通過(guò)這三個(gè)指標(biāo)1. 一個(gè)是HEIGHT要大于等于4,這個(gè)高度指的是什么意思呢,這個(gè)高度指的是層次,就是1樓,2樓,3樓,4樓,這個(gè)高度一共四層,要不然還有一些指標(biāo)2. PCT_USED,這個(gè)應(yīng)該是小于50%的時(shí)候3. 還有一個(gè)指標(biāo)就是這個(gè)DEL_LF_ROWS/LF_ROWS,這個(gè)比值是大于等于0.2的時(shí)候你只要有一個(gè)指標(biāo),超過(guò)這個(gè)值了,證明你這個(gè)數(shù)據(jù)庫(kù),證明你這張表,應(yīng)該進(jìn)行索引碎片的整理了,要不然你這個(gè)性能就慢了,我這里有一個(gè)簡(jiǎn)單的例子

說(shuō)明了索引碎片的問(wèn)題了,咱們來(lái)看一下,這里是一個(gè)很簡(jiǎn)單的例子,creat table t(id int),這里只有一個(gè)字段id,等于int類型的,它是一個(gè)字段,然后我去把他建立一個(gè)索引,creat index ind_1 on t(id),就是把這個(gè)id當(dāng)成一個(gè)索引,給他起個(gè)名字叫ind_1,就是建立一個(gè)索引名字,咱們來(lái)看一下,這個(gè)其實(shí)很簡(jiǎn)單

我當(dāng)前的table中就有一個(gè)t,就有t這張表了,這個(gè)t表是空的,是我剛建立起來(lái)的,然后t表有一個(gè)索引,就是ind_1這個(gè)索引,那咱們可以查看一下,剛才查看索引的這個(gè)SQL

你看到我當(dāng)前有一個(gè)索引了,然后它是存在一個(gè)T表的,它是在T表的ID這一列上的,T表就一個(gè)字段ID,當(dāng)然T表是沒(méi)有任何數(shù)據(jù)的,剛把索引建完,表和索引都建完,然后呢這個(gè)時(shí)候,咱們要做的另外一件事情,就做插入,就做插入一堆數(shù)據(jù),這堆語(yǔ)句是做什么事情的,一般來(lái)講你建表的時(shí)候,要求建表的時(shí)候,直接把應(yīng)該有的索引都建上,這個(gè)性能是比較高的,你不能等表已經(jīng)插入100條數(shù)據(jù)的時(shí)候,然后再建索引,那就不太好了,性能就比較低了,你設(shè)計(jì)一張數(shù)據(jù)庫(kù)表的時(shí)候,一定要想好了,這個(gè)業(yè)務(wù)哪個(gè)字段會(huì)反復(fù)的查詢,直接把索引建好,你最好是這么去做,這是多少次啊,這是一個(gè)簡(jiǎn)單的塊,for in 100萬(wàn)條數(shù)據(jù),然后往里去insert,就是往t表里添加100萬(wàn)條數(shù)據(jù),然后去取模,取模做什么事啊,if mod(i,100)取模就是i這個(gè)值取100,等于0的話,那我就commit提交了,end if,就是往里插數(shù)據(jù),如果那什么的時(shí)候,去模等于0的時(shí)候,去做這個(gè)事,咱們看一下,用Command Window,我就執(zhí)行一下這個(gè),我就回車

這個(gè)過(guò)程可能很慢,你看一下這個(gè)語(yǔ)句,他就是insert into 這么多條數(shù)據(jù),就往這張表里插數(shù)據(jù),只要你這個(gè)取模的時(shí)候,取100等于0的時(shí)候,就commit,提交,然后其他情況就不提交,就跳著來(lái)的,咱們的數(shù)據(jù)可能是1,3,6,...,就少了很多,就咱們不按照順序去走,稍等一下,他這個(gè)過(guò)程可能比較長(zhǎng),100萬(wàn)條數(shù)據(jù)嗎,我這么做的目的其實(shí)就是讓他產(chǎn)生這個(gè)索引碎片的問(wèn)題,一會(huì)我們查一下這個(gè)表,這個(gè)數(shù)據(jù)一定是很多的,然后這樣,它是做這個(gè)事情,分析ind_1,然后這個(gè)節(jié)奏,就是去分析一下,現(xiàn)在肯定是屬于一個(gè)正常的,這個(gè)表里的數(shù)據(jù)都是非常正確的

咱們SELECT COUNT(*) FROM T這張表

里邊一共有這么多條數(shù)據(jù),這塊為了啥啊,就是為了100條提交一次,相當(dāng)于批量處理,這也是100萬(wàn)條數(shù)據(jù),那我當(dāng)前T表中,已經(jīng)有100萬(wàn)條數(shù)據(jù)了,因?yàn)檫@塊就是取模,一旦你取模等于100條的時(shí)候,200條的時(shí)候我也提交一次,300條的時(shí)候我也提交一次,400條的時(shí)候我也提交一次,事務(wù)分批去提交,讓他一次性去提交100萬(wàn),這個(gè)相當(dāng)于性能損耗太多了,就這個(gè)意思,當(dāng)前我們這個(gè)表里已經(jīng)插入100萬(wàn)條數(shù)據(jù)了,這個(gè)表里是一個(gè)最完美的一個(gè)狀態(tài),就是什么啊,剛才我們已經(jīng)遵守了條約了,我在表里沒(méi)有數(shù)據(jù)的時(shí)候,去建立的一個(gè)index索引,然后往里插數(shù)據(jù)的,我插了100萬(wàn)條,就這個(gè)意思,然后現(xiàn)在咱們?nèi)プ鲆患?分析,做這個(gè)語(yǔ)句分析一下這個(gè)索引,咱們?nèi)est

我分析完索引以后,我開(kāi)始得去分析一下,不進(jìn)行分析的話,就是index_stat這張表,如果你不進(jìn)行分析這里面是沒(méi)數(shù)據(jù)的,只有你分析了以后,才會(huì)有數(shù)據(jù),剛才我應(yīng)該不分析,先查一下這個(gè)表,這個(gè)表里面肯定是沒(méi)數(shù)據(jù)的,但是剛才我執(zhí)行完分析以后,他就相當(dāng)于把數(shù)據(jù)插入到index_stats表里了,我們要取的值不就是這幾個(gè)值嗎,高度,一個(gè)PCT_USED,還有一個(gè)就是LF_ROWS的取值,select name,HEIGHT,PCT_USED,DEL_LF_ROWS/LF_ROWS from index_stats

咱們這個(gè)情況是屬于最正常的情況,這個(gè)高度是正常的,咱們看看這個(gè)條件,這個(gè)條件如果是大于等于4,或者小于50%,或者是大于0.2的時(shí)候,無(wú)論哪個(gè)指標(biāo)成立滿足了,就是你張表的索引是有問(wèn)題,你應(yīng)該進(jìn)行索引碎片的整理,就這三個(gè)閥值,那我現(xiàn)在是什么情況啊,我現(xiàn)在這個(gè)HEIGHT高度是幾,我這個(gè)高度是3,屬于一個(gè)理想的狀態(tài),PCT_USED是100%,百分之百就是相當(dāng)于使用率很高,因?yàn)槲一旧蠜](méi)有做其他的操作,你只有小于50%了,你這個(gè)使用率小于50%了,你得碎片整理,如果你大于50%,甚至60%,70%,100%,非常完美的情況下,你都不用做,這個(gè)查詢速率是很高的,或者是這個(gè)值大于0.2,我這個(gè)值是多少啊,我這個(gè)值是0,那肯定是小于0.2的,目前來(lái)講,剛才我做了這個(gè)操作,我查的時(shí)候肯定是走索引的,他這個(gè)性能一定是最佳的,肯定是跟咱們的索引是沒(méi)關(guān)系的,但是接下來(lái)我要做的事是破壞他,我怎么破壞呢,我這樣,我去批量的DELETE,delete t where rownum < 700000,這是多少,rownum只要小于70萬(wàn)的,我一下子刪除了70%的數(shù)據(jù),一共100萬(wàn)條,我刪除了70%的數(shù)據(jù),你說(shuō)他肯定會(huì)對(duì)這個(gè)索引的碎片,造成很大的影響,咱們來(lái)做一下這個(gè)事情吧,那這個(gè)刪除操作稍微等一下,就是已經(jīng)刪除69萬(wàn)9999條數(shù)據(jù)

然后commit提交,提交事務(wù),然后我們?cè)俅稳ELECT COUNT(*) FROM T這張表

這里面就是30萬(wàn)01條了,那么這個(gè)時(shí)候,我再去做這個(gè)事情,我再去查還是一樣的

他沒(méi)有變化是為什么呢,說(shuō)明了一件事情,這三個(gè)指標(biāo)為什么沒(méi)有變,原因是你必須去分析一下,之后才會(huì)把分析之后的結(jié)果放到index_stats這張表里,把那個(gè)覆蓋掉了,所以你還是的Copy一下,再分析一下,分析完了之后再查

這回你會(huì)發(fā)現(xiàn),比如這個(gè)指標(biāo)高度沒(méi)有什么變化,或者使用率也沒(méi)有什么變化,但是最后一個(gè)指標(biāo)變得非常高,他肯定是大于0.2的,剛才我說(shuō)的索引碎片量化的指標(biāo),是這樣的,是這三個(gè)條件只要滿足一個(gè),那就是你這個(gè)表的索引就必須得進(jìn)行碎片的整理了,他會(huì)有索引碎片的問(wèn)題,他查詢的效率就比較低了,那肯定滿足DEL_LF_ROWS/LF_ROWS>0.2了,現(xiàn)在是0.69999了,那肯定是需要整理的,除了DELETE還有其他的操作,會(huì)影響其它兩個(gè)參數(shù),比如UPDATE,比如insert,可能會(huì)影響前面兩個(gè)參數(shù),或者你把原先索引ID等于1,你直接把ID改成幾了,那這個(gè)都是會(huì)有影響,可能會(huì)影響上面兩個(gè)指標(biāo),接下來(lái)是如何整理索引碎片的問(wèn)題,我記得是ORACLE 10g以后,官方里面出的時(shí)候就說(shuō),我們的ORACLE能在線進(jìn)行索引碎片整理,通過(guò)這個(gè)語(yǔ)句,alter index ind_1 rebuild [online] [tablespace name],alter index,ind_1這個(gè)index,ind_1是你自己的索引名,然后rebuild重新重構(gòu),重新整理一下這個(gè)索引,然后有幾個(gè)參數(shù)可選的,你可以選表空間,這里有一個(gè)rebuild [online],在線的整理,什么意思呢之前92的時(shí)候沒(méi)有這個(gè)功能,什么功能,你要整理索引碎片的問(wèn)題,之前這個(gè)表跑了好幾年了,4,5年了,發(fā)現(xiàn)跑的性能越來(lái)越慢,然后我要重新整理,我該怎么辦啊,只有把服務(wù)停了,把表鎖住了,把另外一張新表進(jìn)行整理,怎么怎么辦,他現(xiàn)在有一個(gè)這樣的功能,你這邊不影響你表的查詢,然后我還可以給你進(jìn)行整理索引,就是rebuild online,我們加上這個(gè)參數(shù)看一下,我可以直接test,然后后面加上一個(gè)online,可以指定表空間的無(wú)所謂啊,這個(gè)無(wú)所謂了,我在這里就不測(cè)試表空間了

然后瞬間就整理完了,整理完了之后,然后我們?cè)偃タ磗tat這塊,他就會(huì)把之前的清空了

你重新rebuild online了,再次去分析一下,分析完了以后,整理完了以后

剛才說(shuō)了一個(gè)事,什么時(shí)候會(huì)產(chǎn)生索引碎片的問(wèn)題,里面有量化指標(biāo),當(dāng)HEIGHT這個(gè)東西大于等于4,或者PCT_USED小于50%,或者DEL_LF_ROWS/LF_ROWS>0.2的時(shí)候,我現(xiàn)在整理,2是不是小于4,小于4說(shuō)明高度是沒(méi)有問(wèn)題,通過(guò)了我這個(gè)指標(biāo),PCT_USED小于50%的時(shí)候說(shuō)明你索引碎片是有問(wèn)題了,那這個(gè)90依然是沒(méi)有問(wèn)題,DEL_LF_ROWS/LF_ROWS直接降到0了,那這樣的話就會(huì)把我這個(gè)表,變得很完美,很完整,就是你可以做一個(gè)整理表的這個(gè)事,當(dāng)然在真正的工作中,一般都是這么去用的,都是在數(shù)據(jù)庫(kù)表跑一段時(shí)間以后,舉個(gè)例子吧,其實(shí)還有一種方案,我把一張表的數(shù)據(jù)導(dǎo)到一張新表里,然后再去做一個(gè)索引,重新放在一個(gè)新表里,把這個(gè)索引的表都干掉,放在第一個(gè)新的表里,一個(gè)非常完美的表里,沒(méi)有任何索引碎片的問(wèn)題,但是你想想,你要整理索引碎片的這張表,數(shù)據(jù)量一定是很大,肯定是幾億,幾十億,那你導(dǎo)的過(guò)程肯定是耗時(shí)的,你需要幾個(gè)小時(shí),甚至更久,那我倒不如怎么辦,rebuild online先把這個(gè)索引碎片問(wèn)題解決掉,查詢效率高一點(diǎn),然后我這邊自己慢慢地去做一些操作,比如把數(shù)據(jù)重新導(dǎo)入到一張新表里,當(dāng)這個(gè)導(dǎo)完了之后,所有的都建好了以后,然后大不了把這張表干掉唄,然后再切換回來(lái),切換到各個(gè)指標(biāo)都非常完美的這張表里,再慢慢的去使用,這就是相當(dāng)于ORACLE做索引碎片整理的問(wèn)題,你們用MYSQL的時(shí)候,有碰到這個(gè)問(wèn)題是怎么解決的,MYSQL應(yīng)該是沒(méi)有這個(gè)功能的,可能你們用MYSQL用的比較熟,大體上就是說(shuō)一下索引碎片的問(wèn)題,總之你一張表用的時(shí)間久了,你肯定需要頻繁的修改刪除,那肯定會(huì)造成你查詢的效率會(huì)越來(lái)越慢,索引也就越來(lái)越慢,那肯定是需要整理

?

總結(jié)

以上是生活随笔為你收集整理的Oracle之索引和索引碎片问题解决的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。