mysql下，某business单表已近2000万且还在持续增加中,存在多个索引，有较高的查询压力。现业务端使用guava cache拦了一道，还能顶得住，但是后台管理系统的全量数据的分页排序查询比较慢，且将来会越来越慢。
业务端+admin查询都快。
三、解决方案
1.基于实际情况（
大家一定要根据实际情况来
），把数据库拆为三个，如下：
热数据(老表)：提供CURD操作
，事务加锁等等，最大限度的不用更改原代码。
半年内数据（history）：只提供查询业务。
半年之前数据(backup)：归档，不提供业务查询
，只支持手动查库
(已跟产品沟通好)。
2.数据迁移，采用公司统一任务调度平台，注册任务后调度执行，自带WEB管理页面。支持暂停、恢复、执行计划、日志查询。
3.由于历史数据过千万，需要上线前进行一次手动迁移，初始化数据
1）history表保存：7天~半年，非进行状态的数据。
2）backup表保存：半年前的，非进行状态的数据。
3）删除business表中，7天前的，非进行状态的数据。
4. 后续每天凌晨定时任务迁移数据（迁移时注意：保证ID一致 ）
business-->history >7天，非进行状态的数据。
history-->backup >半年，非进行状态的数据。
5.admin切到从库读。主从分离,避免从库读全量数据，导致业务端查询缓慢。
1.千万级带索引删除记录，记得
不能一次性直接delete,
可以根据创建时间来，一次删除百万级数据，
多分几次删除
。否则容易出现假死，慢查询，kill不掉执行sql.
2.注意初始化数据时候，可能当天多次执行，所以
加上修改时间在当天前的，这样多次执行，不会出现数据重复
。
3.写批量
插入sql
时，
1）
不要用函数
：sql中使用函数极端消耗时间。
2）
不要用#，要用$
：避免再次编译消耗时间，这里不用怕什么sql注入，内部接口。
1 <insert id="transferTradingOrderByIds">
2 insert into ${toTableName} (<include refid="Base_Column_List"/>)
3 select <include refid="Base_Column_List"/>
4 from ${fromTableName}
5 <where>
6 id in
7 <foreach collection="transferTradingOrderIds" item="id" separator="," open="(" close=")">
8 ${id}
9 </foreach>
10 </where>
11 </insert>
热表数据:一百万内，增删改查极快。
历史数据:一千万内，查询快。
归档数据：千万级以上，慢，但是业务不调用。
