一次查询优化

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

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

以上是关于一次查询优化的主要内容,如果未能解决你的问题,请参考以下文章

记录一次sql优化查询

记一次查询性能优化,原30s+,现0.5s~20s

记一次SQL性能优化,查询时间从4000ms优化到200ms.

一次SQL查询优化原理分析(900W+数据,从17s到300ms)

MYSQL一次千万级连表查询优化

记一次数据查询优化