由于公司業務，采用了大表磁區的方案，我創建了組合磁區，子磁區是按照天進行磁區，現在是想統計1個月的資料，也就是需要跨30個磁區，資料量大概在2000萬左右，磁區欄位都變成磁區索引了，統計總數的時候，如果只用磁區索引，速度很快，但是加上一些別的欄位速度特別慢，新加的欄位只有1，0兩種資料，所以不適合加索引，試過了磁區的本地索引和全域索引，效果都不佳，貼上sql，求哪路大神幫忙。
select count(1)
from send_new2 t
where 1 = 1
and t.send_status = '6'
and t.sys_time between
to_date('2017-02-02 04:02:07', 'yyyy-mm-dd hh24:mi:ss') and
to_date('2017-03-20 03:02:07', 'yyyy-mm-dd hh24:mi:ss')
and t.IS_ORIGINAL_SMS=0 ---》這個is_original_sms 不是磁區欄位，只有0，1 兩種形式，send_status 是父磁區鍵，sys_time是子磁區鍵。只用磁區索引的話，2000萬以上的資料統計在2-3秒，加上這個欄位200秒都查不出來。
uj5u.com熱心網友回復：
欄位只有1，0兩種資料，可以創建位圖索引。uj5u.com熱心網友回復：
這個只有1，0的欄位是我舉得一個例子，因為是大表，在開發人員實際開發中不知道會用到什么欄位，一旦用到磁區索引之外的欄位就會有這種查詢慢的情況發生，我是想有沒有更好的解決方式。
uj5u.com熱心網友回復：
你的資料量并不算大，我們這里生產的歷史資料幾十億條記錄。關鍵是有沒有建好索引。表中最好有個用Sequences記錄的欄位。
你這是單表不是多表關聯查詢本不會很慢。你將你的SQL放到
PL/SQL Developer里按F5看下有沒有走索引。
另外建議建個索引表空間，并且send_status欄位用數字型，不要用字符型
建一個send_status、sys_time、IS_ORIGINAL_SMS三個欄位的組合索引將索引放到索引表空間里。
不要放到資料的表空間里
uj5u.com熱心網友回復：
幾個疑問或需要提供的資訊：1、你很快的時候，有send_status字典嗎？還是就只有sys_time？
2、sys_time是不是個非空欄位？
3、你的第一層磁區鍵是什么欄位？為什么時間欄位會是第二層的磁區鍵而不是第一層的？
4、“磁區欄位都變成磁區索引了”，這意思是不是磁區欄位上都創建了磁區索引？也就是說至少磁區欄位sys_time上有單欄位索引？還是它與第一層的磁區鍵上創建了組合索引？順序如何？如果是的話，那么這個組合索引中的欄位是不是不可能全部為空？
5、單月總資料量為2000w，那么加上其他欄位過濾后，這個資料量是否也可控？比如縮小到了20萬？或者根本不可控，可能是200條，也可能還是200萬？
6、給出快的時候的執行計劃。
uj5u.com熱心網友回復：
1.很快的時候用的是兩個欄位，send_status,sys_time
2.不是非空欄位，但是資料不會為空。
3.第一層用的是send_status,應為業務需要，有其他的專案同時用到同一張表的send_status欄位，但是沒有用到sys_time欄位，考慮到如果用時間的話可能需要重寫一部分sql，因為用到的專案比較多，考慮到部署的問題，就用send_status作為第一層。
4.是組合索引，send_status sys_time的順序，一定不會全為空。
5.是不可控的 ，因為查詢的話可能不一定查詢多大的時間跨度，而且還有一些其他的無法建成索引的欄位，查詢量很不固定。
6.執行計劃如下 這個是快的磁區索引：
Execution Plan
----------------------------------------------------------
Plan hash value: 1600035421
--------------------------------------------------------------------------------
----------------------------------------
| Id | Operation | Name | Rows | Bytes |
Cost (%CPU)| Time | Pstart| Pstop |
--------------------------------------------------------------------------------
----------------------------------------
| 0 | SELECT STATEMENT | | 1 | 11 |
7864 (1)| 00:01:35 | | |
| 1 | SORT AGGREGATE | | 1 | 11 |
| | | |
| 2 | PARTITION LIST SINGLE | | 2557K| 26M|
7864 (1)| 00:01:35 | KEY | KEY |
| 3 | PARTITION RANGE ITERATOR| | 2557K| 26M|
7864 (1)| 00:01:35 | 34 | 80 |
|* 4 | INDEX RANGE SCAN | IDX_SEND_PAR_NEW_20150501 | 2557K| 26M|
7864 (1)| 00:01:35 | | |
--------------------------------------------------------------------------------
----------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("T"."SEND_STATUS"=6 AND "T"."SYS_TIME">=TO_DATE(' 2017-02-02 04:02
:07', 'syyyy-mm-dd hh24:mi:ss')
AND "T"."SYS_TIME"<=TO_DATE(' 2017-03-20 03:02:07', 'syyyy-mm-dd h
h24:mi:ss'))
這個是慢的執行計劃：
Execution Plan
----------------------------------------------------------
Plan hash value: 3591182293
--------------------------------------------------------------------------------
--------------------------------------------------
| Id | Operation | Name | Rows
| Bytes | Cost (%CPU)| Time | Pstart| Pstop |
--------------------------------------------------------------------------------
--------------------------------------------------
| 0 | SELECT STATEMENT | | 1
| 14 | 1847 (1)| 00:00:23 | | |
| 1 | SORT AGGREGATE | | 1
| 14 | | | | |
| 2 | PARTITION LIST SINGLE | | 10797
| 147K| 1847 (1)| 00:00:23 | KEY | KEY |
| 3 | PARTITION RANGE ITERATOR | | 10797
| 147K| 1847 (1)| 00:00:23 | 34 | 52 |
|* 4 | TABLE ACCESS BY LOCAL INDEX ROWID| SEND_NEW2 | 10797
| 147K| 1847 (1)| 00:00:23 | | |
|* 5 | INDEX RANGE SCAN | IDX_SEND_PAR_NEW_20150501 | 10797
| | 36 (0)| 00:00:01 | | |
--------------------------------------------------------------------------------
--------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - filter("T"."IS_ORIGINAL_SMS"=0)
5 - access("T"."SEND_STATUS"=6 AND "T"."SYS_TIME">=TO_DATE(' 2017-02-02 04:02
:07', 'syyyy-mm-dd hh24:mi:ss') AND
"T"."SYS_TIME"<=TO_DATE(' 2017-02-20 03:02:07', 'syyyy-mm-dd hh24:
mi:ss'))
uj5u.com熱心網友回復：
兩個計劃的區別就是，第二個差的有返表操作：TABLE ACCESS BY LOCAL INDEX ROWID所以，能做的優化就是把額外的條件欄位也加入到組合索引中，但是，如果如果這個額外的條件也是很多變的話，除了位圖索引（當然原有的組合索引也要拆成兩條位圖索引比較好），還真不好優化了。、
另外，你的主鍵呢？主鍵包含磁區鍵嗎？還是你現在主鍵就是兩個磁區鍵的組合？
uj5u.com熱心網友回復：
主鍵跟磁區鍵無關，這個表只有一個主鍵，不是聯合主鍵。主要是考慮表的欄位較多，開發人員用到的篩選條件比較雜，不一定會用到哪些欄位，而且不能把他們用到的欄位都加到索引，所以這個問題不太好解決。
uj5u.com熱心網友回復：
之前我看執行計劃也是看到了這個回表的問題，這個回表可以避免嗎？
uj5u.com熱心網友回復：
還好是count，否則連只有兩個磁區鍵條件的查詢都會比較慘，而一旦加入了其他欄位，那么這個返表操作肯定是逃不掉了，除非用磁區掃描來替代索引，但至少也要掃描2000萬資料，想來性能也不會好……
如果條件組合非常多，那么位圖索引可以說是不多的選擇了。
uj5u.com熱心網友回復：
沒啥好辦法，請加上并行吧
uj5u.com熱心網友回復：
加并行？那就刺激了
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/77949.html
標籤：基礎和管理