IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

一次SQL优化记录

信春哥,系统稳,闭眼上线不回滚 2012-10-22 21:53:05 累计浏览 6,072 次
本机暂存

在给客户巡检时,发现一个用PL/SQL Developer执行的效率低下SQL,如下:

原图已失效

SQL语句如下:

UPDATE TS_R_ORDER_DAY_004_TEMP A
   SET USER_TAG =
       (select z.USER_TAG
          from (SELECT USER_TAG,
                       ORDER_ID,
                       ROW_NUMBER() OVER(PARTITION BY ORDER_ID ORDER BY CLCT_DAY DESC) RN
                  FROM TS_UH_ORDER_GOODS) z
         where A.ORDER_ID = z.ORDER_ID
           and rn = 1)
 WHERE EXISTS
 (SELECT 1 FROM TS_UH_ORDER_GOODS X WHERE A.ORDER_ID = X.ORDER_ID)

SQL执行计划如下:

原图已失效

通过执行计划可以看到,对Cost影响较大部分为IDX_TS_UH_ORDER_GOODS_1表的索引跳扫,Cost值157,虽然只有157,但是对走索引来说,157的Cost已经很大了,如果正常索引扫,这个值会小很多,而且INDEX SKIP SCAN的结果和HASH JOIN SEMI循环,导致总Cost达到287M(100),如果能将索引跳扫的Cost从157降下来,INDEX SKIP SCAN的结果和HASH JOIN SEMI循环的总Cost就会成几何下将,这个SQL优化重点也是使索引跳扫改成正常索引扫,猜测产生索引跳扫的原因可能是IDX_TS_UH_ORDER_GOODS_1表上存在复合索引,而该表的ORDER_ID列不是复合索引的第一列,解决方法:在IDX_TS_UH_ORDER_GOODS_1表的ORDER_ID列上单独建立索引。

但是无法接触客户的生产环境,只能给客户建议,至于客户会不会按照建议调试就是未知数了,而且这个SQL只执行了一次,也许这个SQL的运行时间客户是可以接受的,期待客户反馈。

同分类推荐文章

  1. 使用deepseek进行Oracle恢复,引起重大故障 (2026-06-22 10:56:00)
  2. 接手一个只差临门一脚的数据库恢复 (2026-06-18 00:13:09)
  3. 我做了一个 AI 版的 StarRocks 升级风险扫描工具,直接帮我定位到一个风险 (2026-06-15 01:00:00)

查看更多 数据库 文章 →

建议继续学习

  1. 如何建立合适的索引? (累计阅读 6,781)
  2. 改变了对Mysql子查询的看法 (累计阅读 3,981)
  3. Mysql执行计划中的Using filesort (累计阅读 3,341)
  4. 说oracle优化之一 (累计阅读 3,339)
  5. Virtual Indexes (累计阅读 3,247)
  6. 拒绝等死,大步向前 (累计阅读 2,386)
  7. the ways to kill mysql application performance (累计阅读 2,346)
  8. Hint的常见错误使用方式 (累计阅读 2,345)
  9. 执行计划中常见index访问方式 (累计阅读 2,214)
  10. BITMAP CONVERSION 执行计划导致CPU 100% (累计阅读 2,079)