資料庫大資料量表SQL語句執行耗時久

起因：介面傳輸資料慢，出現超時情況。原因：表資料量龐大，執行查詢操作時耗時久。雖然建立了索引，但是沒有效果，沒有走索引。資料庫：oracle

explain plan for slow sql; 

select * from table
(dbms_xplan.display)
;

注：explain plan for後接sql語句。

解決：分析表。

analyze table tablename compute statistics

總結一：常見索引掃瞄型別

索引唯一掃瞄，當可以優化器發現某個查詢條件可以利用到主鍵、唯一鍵、具有外來鍵約束的列，或者只是訪問其中某行索引所在的資料的時候，優化器會選擇這種掃瞄型別。

索引範圍掃瞄，當優化器發現在unique列上使用了大於、小於、大於等於、小於等於以及between等就會使用範圍掃瞄，在組合列上只使用部分進行查詢，導致查詢出多行資料。對非唯一的索引列上進行任何活動都會使用index range scan。

全索引掃瞄，如果要查詢的資料可以全部從索引中獲取，則使用全索引掃瞄。

索引快速掃瞄，掃瞄索引中的全部的資料塊，與全索引掃瞄的方式基本上類似。兩者之間的明顯的區別是，索引快速掃瞄對查詢的資料不進行排序，資料返回的時候不是排序的。「在這種訪問方法中，可以使用多塊讀功能，也可以使用並行讀入，從而得到最大的吞吐量和縮短執行時間」。

總結二：可能不走索引的情況

1、where 中字段沒建立索引，不走索引。

2、長時間沒做表分析或者重新收集表狀態資訊，不走索引。
3、索引列使用函式，需建立函式索引。
4、對索引列進行了加減乘除運算，不走索引。
5、where中使用 is null 和 is not null。
6、where中使用 like '%%' 進行模糊查詢。
7、where中使用<
>、not in 、not exist。
8、資料型別不匹配，例如：select * from tablewhere jlbh =
1；jlbh為varchar2型別字段
9、單獨引用復合索引裡非第一位置的索引列。
10、索引失效，可以考慮重建索引，rebuild online。

大資料量表刪除插入

1。alter table t nologging 不記錄日誌，完成後記錄日誌。2。先停用索引，在全部操作完成後啟用索引。3。多次小批量提交。4。選擇業務操作量少的時間進行。create or replace procedure delbigtab p tablename in varchar2,p...

快速刪除大資料量表

要清空表中資料，100w條資料以上的表，開始我們使用delete from t user進行刪除，這樣操作太慢了，需要等好長時間，如果資料量更大，那麼我們要等的時間無法想象。可以用以下方法進行刪除 假設要刪除的原表為source t 1.第一步生成中間表 create table source t ...

設計大資料量表結構

上篇文章講解了傳統資料庫的一些設計注意點。本篇為第二篇，在大資料量的情況下，如何去提前設計這個表結構，來達到乙個比較好的效果。對於團隊，對於後續的維護和擴充套件都帶來更大的便利。自增id 自增id還是可以有，但是不是必須的了。但是建議還是每張表中有乙個自增id。為什麼，還是那句話，做資料查詢，遷移，...