一次優化的談論:sql
在QQ羣中 又看到問以下sql插入爲何會這麼慢?正好羣裏面有個優化大事順便給咱們上了一課,我就順手記錄一下。數據庫
你們的優化思路:session
一、忽然變慢的話, 你查詢一下目前數據庫 中正在經歷的等待事件哈。app
二、append hit (這個能夠)性能
三、並行 (生產不建議開並行,對性能消耗很大)優化
四、 MERGE INTO (MERGE INTO 最大的用處不在這邊, 在那種業務,關聯更新, 或者要麼沒有就插入,有就更新的業務。 merge into 精妙之處在於 能夠走兩種執行計劃。)spa
五、nologging (思想能夠,可是沒有見過在insert 有這個).net
最後的優化思路:blog
先找緣由 在優化索引
1 弄清楚是 insert 慢仍是 select 慢。那個慢就搞那個 2 明顯這個語句是在執行哈, 咱們就能夠經過 v$session 這個試圖觀察這個 sql 執行過程當中的等待事件, 針對等待事件做出處理, 3 另外 session這個試圖中也能夠看到, 有沒有被阻塞啊。
insert的時候呢, 你的undo 塊多很少, 若是插入的數據量很大, 你比一次插50G的數據。。。 那完蛋了, 很差優化了, 你想啊, 你沒事1個事物,插入50G的數據, 那還優化個, 呵呵。。 趕忙作 大事物切片去吧
好比, insert時候, 都被阻塞了。。 insert阻塞是很常見的, 這個不舉例子了。之後說
好比 insert慢的時候呢, 你要維護啊, 維護索引形成巨大的開銷呢? 典型的索引分裂。。。
那你趕忙去作,索引熱點塊,散熱啊。。。
是的額,索引會致使DML慢
若是Select 慢,那就首先去看一下是否有標量子查詢。標量子查詢 須要改成外連接
看錶數據量大小,找驅動表,創建索引
你看錶, tem這個表, 看着像臨時表啊, 是否有統計信息啊。由於臨時表,若是沒有統計信息的話,會動態採樣的。
可是我遇到好幾個案例, 這個表就不能收集統計信息, 一收集, SQl就慢了。。
看下這個查詢 用使用到B表的兩個字段,這樣咱們能夠考慮下是否在B表的兩個字段建立索引,就是說用索引掃描代替 全表掃描, 減小數據掃描的總量仍是能夠的,那麼問題來了,這個索引還怎麼建立呢?
index (B 表兩個字段), 仍是 index(B 表兩個字段,0)?這裏引深一下,索引不存儲null值,那麼爲了不null值索引失效的問題,咱們通常會在要建立索引字段後面叫一個常量,好比create idx_id on t(id,0),無論id是否有null值,可是組合索引都不會存儲null,這個索引就不會失效。
回到這個話題,若是 where A.OLDER_ID=B.OLDER_ID,那麼 咱們可使用 index (B 表兩個字段),由於等值關聯不存在空值,若是是where A.OLDER_ID(+)=B.OLDER_ID,也可使用 index (B 表兩個字段),右鏈接能夠確保 B表沒有NULL值。若是是左鏈接A.OLDER_ID(+)=B.OLDER_ID(+),那麼B表是有可能存在null值,因此必須的使用 index(B 表兩個字段,0) 這種方式建立索引。
固然也能夠在select 查詢開多快alter session set db_file_multiblock_read_count=128;)
好比, 到最後呢。 看等待事件, 好比多快讀等待事件。
https://blog.csdn.net/daiqiulong2/article/details/81513084 優化大神的博客。