这篇文章主要讲解了“怎么解决数据库LOB字段带来的性能影响”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么解决数据库LOB字段带来的性能影响”吧！

10年积累的成都网站建设、做网站经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先做网站设计后付款的网站建设流程，更有余干免费网站建设让你可以放心的选择与我们合作。

今天开发人员反映一个SQL查询时间大概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

分析：

       该语句从执行计划来看，走了时间索引，返回记录是1千多，如果全部查询出来进度很慢（分页的翻页操作很慢），后来发现该语句的性能主要是消耗在：字段"Question"，“MailContents”,"Category"和"ReplyContent"上，把这4个字段注释小，查询时间在5s内，后来发现这4个字段为CLOB字段类型,因为CLOB字段这种字段类型的存储方式是比较复杂的，如果该CLOB字段内容超出一定值，会用指针指向另一个SEGMENT，把内容存放在新的SEGMENT; 这样当访问的时候，会出现IO次数增加,从而影响性能，并且CLOB类型有独立的回滚机制，当一致性读的行数较多时，响应时间很慢，而就算存储的内容较小，CLOB本身也会调用系统内部的函数进行匹配和寻址，也是很消耗CPU时间的.

解决方案：

        经与开发人员沟通，该表的此四个字段其实实际存储内容远没有超出4000个字节（varchar2的最大长度），当初设计的时候没有考虑精准，于是计划把这些字段类型按照下列方法重新调整：

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内。

感谢各位的阅读，以上就是“怎么解决数据库LOB字段带来的性能影响”的内容了，经过本文的学习后，相信大家对怎么解决数据库LOB字段带来的性能影响这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！

文章题目：怎么解决数据库LOB字段带来的性能影响
本文链接：http://ybzwz.com/article/iiidgd.html