分页查询列表每页1000条的优化

项目中有一个客户列表,要求每页显示1000条,并且字段很多,接口返回大概要10秒钟,进行优化.
原本逻辑:使用mybatisplus构建查询条件,分页查询客户表,查出数据库DO对象,然后for循环转化成回显的VO对象.在转化的过程中出现了查库代码,导致当每页条数1000时,每一个客户转化都需要查询一次,造成了几千次的IO.
前提条件,已经构建了相关的索引.
首次优化,避免在转换VO的过程中出现查库代码,提前收集客户id列表,查询相关的员工信息,部门信息等等,并根据关联id转成一个map,把map直接放到转换代码中,这样只查一次,多次使用

第二点优化:如果数量大于100条时,每个线程100条,多个线程同时执行

第三处优化:其实查询sql并不算很慢,但是因为对象很大,转换的过程比较慢,直接使用mybatis查询mybatisplus构建的条件,使查出的结果直接是客户VO而不是客户DO,省略了复制转换的过程

    Page<ClientListVO> paging(@Param("page") Page<ClientListVO> cachePage, @Param(Constants.WRAPPER) LambdaQueryWrapper<ClientDO> wrapper);

        <select id="paging" resultType="com.ruoyi.system.domain.vo.ClientListVO">
            select * from client ${ew.getCustomSqlSegment}
    </select>

为什么能直接在 MyBatis XML 中使用 Wrapper？
MyBatis-Plus 在底层做了以下处理：

参数绑定：通过 @Param(Constants.WRAPPER) 注解，将 wrapper 对象绑定到 ew 变量名。

SQL 解析：Wrapper 内部会解析你调用的方法（如 eq(), orderBy()），生成对应的 SQL 片段。

变量替换：在 XML 中，${ew.getCustomSqlSegment} 会调用 wrapper.getCustomSqlSegment() 方法，返回生成的 SQL 片段。

经过多次优化以后接口查询1000条仅用时几百毫秒.