背景：

關(guān)于這個(gè)標(biāo)題想了試了好幾個(gè)總覺得欠那么點(diǎn)意思。大致情況是，在某服務(wù)支持中，1張大表4.5T左右，該表也是分區(qū)表。其中一個(gè)執(zhí)行頻繁的SQL寫法有很大問題，導(dǎo)致巨表全量掃描，造成IO負(fù)載很大，業(yè)務(wù)收到嚴(yán)重影響。

?由于線上階段基本上沒有改SQL的可能， 只能通過其他途徑優(yōu)化。現(xiàn)場想到一種可行的方案，周末實(shí)在手癢，決定測試測試該方案理論上的可行性。

基本情況：

數(shù)據(jù)庫：Oracle 11G

表情況：4.5T左右，二級分區(qū)表，3.9萬分區(qū)，分區(qū)如果有數(shù)據(jù)的話，數(shù)據(jù)量不大大概是2-3G左右。

分區(qū)字段：數(shù)據(jù)日期+XXX字段。

分區(qū):range-range(應(yīng)該是range-range這邊有點(diǎn)模糊)

SQL情況

SQL比較長，也有好多張表關(guān)聯(lián)，這邊只重點(diǎn)說出現(xiàn)性能瓶頸的地方，

SQL：where trunc(分區(qū)字段)=trunc(XX, yyyy-mm-dd) and XX like :B ;

導(dǎo)致識別不了分區(qū)，只能全分區(qū)掃描。

本機(jī)測試

表：par_range_range

分區(qū)類型:range-range;?

分區(qū)字段:data_dt (DATE類型); ?hash_flag (number類型)

SQL：模擬生產(chǎn)環(huán)境出現(xiàn)的問題

select? count(1) from?? par_range_range t

where? hash_flag <1.5 and? hash_flag>=0.1

andtrunc(data_dt) = trunc(to_date('2020-11-01', 'yyyy-mm-dd'));

問題就是 trunc(data_dt) 無法識別那個(gè)分區(qū)只能走全分區(qū)掃描，有經(jīng)驗(yàn)的人立馬知道怎么搞，實(shí)際中把搞成 trunc(to_date('2020-11-01', 'yyyy-mm-dd'))<= data_dt < to_date('2020-11-02','yyyy-mm-dd')。現(xiàn)場調(diào)整后也是秒殺的，但是甲方需要不改SQL，就能優(yōu)化。

實(shí)驗(yàn)課題：

通過建立索引優(yōu)化該SQL,(該問題引發(fā)一系列思考)

探索巨表建立索引方案(其實(shí)這里更感興趣)

通過建立合適索引把全表掃描轉(zhuǎn)換成索引掃描

巨表怎么建立索引？保證不會占用太多系統(tǒng)資源，比如IO，內(nèi)存，temp. 甚 至做到系統(tǒng)無感知。因?yàn)橐呀?jīng)出現(xiàn)了掃描巨表數(shù)據(jù)時(shí)候IO超負(fù)載。

前兩個(gè)可行基礎(chǔ)上加快建索引速度

這怎么看都是一個(gè)不可能完成的任務(wù)。

這里說下最終方案：

建立需要分區(qū)索引，建索引時(shí)候也要講究，最初建索引的語句要帶上unusable 關(guān)鍵字，這樣建索引時(shí)候就不會創(chuàng)建索引段，自然也不會掃描表數(shù)據(jù)。所以這邊建立索引能很快完成。

隨即按照分區(qū)，重建分區(qū)索引。因?yàn)檫@邊只需要掃描單個(gè)表分區(qū)，就能很快完成對應(yīng)分區(qū)索引的重建，畢竟掃描數(shù)據(jù)量小了很多。因此整體方案理論上可行。

數(shù)據(jù)量：445萬，722M ，本機(jī)測試環(huán)境，數(shù)據(jù)量有限。這邊測試原理

建立索引語句：

create?? index?idx_prr_dt_flag? on?

par_range_range(trunc(data_dt),hash_flag) local? unusable;

測試環(huán)境中很快完成。

建立后查詢索引分區(qū)：

重建分區(qū)索引。

重建完成后，這邊只查詢到重建的索引分區(qū)的segement。說明符合預(yù)期，只有在rebulid時(shí)候才創(chuàng)建索引segement。

優(yōu)化效果(重建完所有分區(qū)后)：

優(yōu)化前：全表掃描 4.3萬邏輯讀/次，

優(yōu)化后：索引范圍掃描，414萬邏輯讀/次 效率提升了近100倍

總結(jié)：

該方案精彩的地方在于把復(fù)雜的大表建立索引，成功轉(zhuǎn)換成更加細(xì)微力度的建立分區(qū)索引,解決了大表建立索引過程中帶來的IO，內(nèi)存等系統(tǒng)資源占用率超大等問題。而重建分區(qū)索引，單個(gè)分區(qū)的數(shù)據(jù)量要小得多，當(dāng)然重建也容易的多。最終把問題SQl成功優(yōu)化。

結(jié)束語：

本文就是利用延遲加載，完成超大表建立索引，然后再實(shí)踐中總結(jié)知識點(diǎn)。用論語中一句話結(jié)尾吧。論語：知之為知之，不知為不知。我在想是不是可以這樣“探索”，知之，為，知之！，不知為，不知。可以這樣解讀：掌握一門知識，并且賦予實(shí)踐。然后在實(shí)踐中再總結(jié)知識。不了解或者不掌握一門知識，直接干，最終是不能總結(jié)出知識的。

總結(jié)

以上是生活随笔為你收集整理的sql 账号查询一个表查询权限_一个查询语句引发的问题以及巨型表相关操作探索与思考...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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