背景：一个业务表：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