内存分页在项目中一般是不推荐使用的,因为效率很低。扫描数据库相关表的所有数据,并全部加载进内存,然后返回需要的数据(可能加载了几万条到内存最终返回5条),极大的消耗了内存。
但在目前负责开发的
场景1 (批量in查询)
在excel批量导入员工数据时,需要以手机号作为唯一条件校验数据是否已存在,若存在,则以excel中的内容,作为最新记录进行更新,若不存在,则直接更新。
这样的操作就会导致每导入一条就必须查一下数据库看数据是否存在,这样效率很低,优化的方法就是,将要导入的员工手机号全部取出后,用手机号作为条件,去数据库中以 in 的方式查找,这样就可以只与数据库进行一次交互,将数据加载到内存中进行判断。
这时就会有个问题:假如导入的数据有5000条,就表示sql拼接的in条件就有5000个参数,Oracle数据库中IN参数个数不能超过1000,否则会报异常。而Mysql中虽然对in无限制,但是sql默认长度是1M (my.ini 中的max_allowed_packet可调节大小) 虽然可以通过参数调节,但是站在程序层面上可能调节成2M也不够,当调的参数过大,Mysql还会自动设置回默认值,站在程序员的角度上,还是从代码角度解决问题比较稳妥。
这时候就可以使用内存分页了,将内存中的数据根据实际情况分批次访问,比起一次次的循环查数据库,效率肯定高,又不至于出现一次in查询导致sql过长而报错。
场景2(模糊查询加密数据)
在业务实现的过程中,有这么一张表:待离职员工临时表,这个表所涉及的业务