码迷,mamicode.com
首页 > 其他好文 > 详细

一次查询优化

时间:2020-04-29 18:08:36      阅读:101      评论:0      收藏:0      [点我收藏+]

标签:生产   索引   tps   文章   com   添加   http   放弃   环境   

  背景:一个业务表:t_biz,两个数据源表:t_remind(提醒待办表),t_remind_record(提醒已办表,数据量非常大,已分区),其他关联表。每次执行任务会查业务表的增量数据和存量数据,都需要关联两个提醒表获取相关字段信息。增量数据在查询时根据业务场景,通过分区字段给定限制条件查询很快。但是存量数据前期设计必须查询代办表和已办表的所有数据。

    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

来源:http://www.totozhan.com/

一次查询优化

标签:生产   索引   tps   文章   com   添加   http   放弃   环境   

原文地址:https://www.cnblogs.com/1156184981651a/p/12803599.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!