一次查询优化

database

    sql 版本1.0:

        最开始由于测试环境待办表和已办表也会有重复数据,是把代办表和已办表查询结果 union all 后,使用下面方式去重,数据量太大,效率很低。

        ROW_NUMBER() OVER(PARTITION BY REMIND_ID ORDER BY REMIND_ID ) RN

    sql 版本2.0:

        由于生产环境待办表和已办表数据不会重复,修改为把已办表查询结果去重后再与待办表查询结果 union all,效率提升很多。

    sql 版本3.0:

        由于业务引入时间晚于提醒数据,历史数据无需查询,添加时间条件限制,同时也是索引列,在之前基础上查询效率进一步提升。生产最后使用此版本。

        由于历史原因,都是先查询代办表和已办表然后 union all ,最开始由存储过程定时执行查出放到中间表;后来数据同步不及时,放弃中间表改用视图。这种方式使得业务表与提醒表关联的字段并不能触发索引的作用,由于提醒数据会一直增长,sql3.0会遇到瓶颈,于是有尝试了另一个版本。

    sql 版本4.0:

        业务表分别关联代办表和已办表(最外层去重),此处与sql2.0比较,查看执行计划已办表没什么区别,还是走分区;代办表索引起作用,效率提高很多;整体查询效率与sql3.0差不多,加上时间限制也没什么变化,可能由于数据量还不大导致的。虽然这个版本sql比较复杂,考虑后面数据量不断加大,认为这种方式加上时间限制限制条件会有更好的表现。

    思考:

    1.要学会查看 sql 执行计划;

    2.尽量使索引、分区起到应有的作用;

    3.慎用视图,不能因为简化 sql 影响 sql 性能;

 

sql优化文章: https://zhuanlan.zhihu.com/p/72071609

以上是 一次查询优化 的全部内容, 来源链接: utcz.com/z/533397.html

回到顶部