一次查询优化
Posted 1156184981651a
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一次查询优化相关的知识,希望对你有一定的参考价值。
背景:一个业务表: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
以上是关于一次查询优化的主要内容,如果未能解决你的问题,请参考以下文章
记一次SQL性能优化,查询时间从4000ms优化到200ms.