背景：

關于這個標題想了試了好幾個總覺得欠那么點意思。大致情況是，在某服務支持中，1張大表4.5T左右，該表也是分區表。其中一個執行頻繁的SQL寫法有很大問題，導致巨表全量掃描，造成IO負載很大，業務收到嚴重影響。

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

基本情況：

數據庫：Oracle 11G

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

分區字段：數據日期+XXX字段。

分區:range-range(應該是range-range這邊有點模糊)

SQL情況

SQL比較長，也有好多張表關聯，這邊只重點說出現性能瓶頸的地方，

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

導致識別不了分區，只能全分區掃描。

本機測試

表：par_range_range

分區類型:range-range;?

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

SQL：模擬生產環境出現的問題

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) 無法識別那個分區只能走全分區掃描，有經驗的人立馬知道怎么搞，實際中把搞成 trunc(to_date('2020-11-01', 'yyyy-mm-dd'))<= data_dt < to_date('2020-11-02','yyyy-mm-dd')。現場調整后也是秒殺的，但是甲方需要不改SQL，就能優化。

實驗課題：

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

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

通過建立合適索引把全表掃描轉換成索引掃描

巨表怎么建立索引？保證不會占用太多系統資源，比如IO，內存，temp. 甚 至做到系統無感知。因為已經出現了掃描巨表數據時候IO超負載。

前兩個可行基礎上加快建索引速度

這怎么看都是一個不可能完成的任務。

這里說下最終方案：

建立需要分區索引，建索引時候也要講究，最初建索引的語句要帶上unusable 關鍵字，這樣建索引時候就不會創建索引段，自然也不會掃描表數據。所以這邊建立索引能很快完成。

隨即按照分區，重建分區索引。因為這邊只需要掃描單個表分區，就能很快完成對應分區索引的重建，畢竟掃描數據量小了很多。因此整體方案理論上可行。

數據量：445萬，722M ，本機測試環境，數據量有限。這邊測試原理

建立索引語句：

create?? index?idx_prr_dt_flag? on?

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

測試環境中很快完成。

建立后查詢索引分區：

重建分區索引。

重建完成后，這邊只查詢到重建的索引分區的segement。說明符合預期，只有在rebulid時候才創建索引segement。

優化效果(重建完所有分區后)：

優化前：全表掃描 4.3萬邏輯讀/次，

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

總結：

該方案精彩的地方在于把復雜的大表建立索引，成功轉換成更加細微力度的建立分區索引,解決了大表建立索引過程中帶來的IO，內存等系統資源占用率超大等問題。而重建分區索引，單個分區的數據量要小得多，當然重建也容易的多。最終把問題SQl成功優化。

結束語：

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。