怎么解決數(shù)據(jù)庫LOB字段帶來的性能影響

這篇文章主要講解了“怎么解決數(shù)據(jù)庫LOB字段帶來的性能影響”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么解決數(shù)據(jù)庫LOB字段帶來的性能影響”吧！

今天開發(fā)人員反映一個(gè)SQL查詢時(shí)間大概2-3分鐘：

SELECT *  FROM (SELECT ROWNUM AS ROWNUMBER__, T.*
          FROM (Select T1.CONSULTINGCODE AS "ConsultingCode",
                       T1.CATEGORY AS "Category",
                       T1.CUSCODE AS "CusCode",
                       T1.ORDERCODE AS "OrderCode",
                       T1.WARECODE AS "WareCode",
                       DECRYPTBYKEY(T1.MOBILEPHONE) AS "MobilePhone",
                       DECRYPTBYKEY(T1.EMAILENCRYPT) AS "EmailEncrypt",
                       T1.ASSIGNTIME AS "AssignTime",
                       T1.REPLIER AS "Replier",
                       T1.REPLYCODE AS "ReplyCode",
                       T1.REPLYDATE AS "ReplyDate",
                       T1.BYWAY AS "ByWay",
                       T1.CREATETIME AS "CreateTime",
                       T1.EVALUATE AS "Evaluate",
                       T1.EXPIREMAN AS "ExpireMan",
                       T1.EXPIREREASON AS "ExpireReason",
                       T1.CONSULTINGTYPEID AS "ConsultingTypeID",
                       T1.STATUS AS "Status",
                      T1.QUESTION AS "Question",
                       T1.MAILCONTENTS AS "MailContents",
                      T1.REPLYCONTENT AS "ReplyContent",
                       T1.ENCEMAIL AS "EncEmail"
                  From mbs7_crm.KH_Consulting T1                  left Join mbs7_crm.KH_Customer T2                    on T1.CUSCODE = T2.CUSCODE                ORDER BY T1.STATUS ASC, T1.CREATETIME ASC) T         WHERE "CreateTime" >= date '2013-9-1'
           AND "ReplyCode"  IN ('128')
           AND "CreateTime" <= timestamp '2013-9-30 23:59:59'
           AND ROWNUM <= 10000) TEMP
                     WHERE ROWNUMBER__ > 0

分析：

       該語句從執(zhí)行計(jì)劃來看，走了時(shí)間索引，返回記錄是1千多，如果全部查詢出來進(jìn)度很慢（分頁的翻頁操作很慢），后來發(fā)現(xiàn)該語句的性能主要是消耗在：字段"Question"，“MailContents”,"Category"和"ReplyContent"上，把這4個(gè)字段注釋小，查詢時(shí)間在5s內(nèi)，后來發(fā)現(xiàn)這4個(gè)字段為CLOB字段類型,因?yàn)镃LOB字段這種字段類型的存儲方式是比較復(fù)雜的，如果該CLOB字段內(nèi)容超出一定值，會用指針指向另一個(gè)SEGMENT，把內(nèi)容存放在新的SEGMENT; 這樣當(dāng)訪問的時(shí)候，會出現(xiàn)IO次數(shù)增加,從而影響性能，并且CLOB類型有獨(dú)立的回滾機(jī)制，當(dāng)一致性讀的行數(shù)較多時(shí)，響應(yīng)時(shí)間很慢，而就算存儲的內(nèi)容較小，CLOB本身也會調(diào)用系統(tǒng)內(nèi)部的函數(shù)進(jìn)行匹配和尋址，也是很消耗CPU時(shí)間的.

解決方案：

        經(jīng)與開發(fā)人員溝通，該表的此四個(gè)字段其實(shí)實(shí)際存儲內(nèi)容遠(yuǎn)沒有超出4000個(gè)字節(jié)（varchar2的最大長度），當(dāng)初設(shè)計(jì)的時(shí)候沒有考慮精準(zhǔn)，于是計(jì)劃把這些字段類型按照下列方法重新調(diào)整：

alter table mbs7_crm.KH_Consulting add  (QUESTION2 varchar2(2000));
update mbs7_crm.KH_Consulting set QUESTION2=dbms_lob.substr(QUESTION,4000);
alter table mbs7_crm.KH_Consulting drop column QUESTION;
alter table mbs7_crm.KH_Consulting rename column QUESTION2 to QUESTION;

修改后，重新查詢，在5S內(nèi)。

感謝各位的閱讀，以上就是“怎么解決數(shù)據(jù)庫LOB字段帶來的性能影響”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對怎么解決數(shù)據(jù)庫LOB字段帶來的性能影響這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！