1. MyBatisPlus排序方法在复杂业务中的实战价值在日常开发中数据排序就像整理书架一样常见但重要。想象一下图书馆的管理系统新书到货需要按入库时间排序读者检索时需要按书名或作者排序热门推荐需要按借阅量排序。MyBatisPlus提供的orderBy系列方法就是帮我们实现这些需求的利器。我接手过一个电商后台项目商品列表需要支持十几种排序方式价格、销量、好评率、上架时间等等。最初用原生MyBatis时每个排序条件都要写动态SQL代码里全是if-else判断。后来改用MyBatisPlus的条件构造器代码量直接减少了60%特别是orderByDesc方法让降序排列变得异常简单。这三个方法的核心区别在于orderBy灵活度最高可自定义每个字段的排序方向orderByDesc专用于降序排列代码语义最明确orderByAsc虽然升序是默认行为但显式声明更易读在用户管理系统中我常用这样的组合queryWrapper.orderByAsc(department) .orderByDesc(salary) .orderByAsc(name);表示先按部门升序同部门按薪资降序最后按姓名升序。这种多级排序在报表类需求中特别实用。2. 多表关联查询中的排序技巧实际项目中最头疼的就是多表关联排序。比如订单系统要显示客户姓名来自user表和商品名称来自product表同时按订单金额排序。这时就需要join操作配合条件构造器。我踩过的坑是直接在关联表字段上排序queryWrapper.orderByDesc(product.price); // 这样写会报错正确做法是先用join方法关联表queryWrapper.select(order.*, user.name as userName, product.name as productName) .eq(order.status, 1) .leftJoin(user, user.id order.user_id) .leftJoin(product, product.id order.product_id) .orderByDesc(order.amount);特别注意join后要使用主表的字段全名如order.amount关联字段要确保有索引否则大数据量时性能很差可以使用select()明确指定返回字段避免N1查询问题在最近的分库分表改造中我发现跨库表的排序要特别注意排序字段必须包含在sharding key中否则会导致全表扫描和内存排序解决方案是建立冗余字段或使用Elasticsearch辅助查询3. 动态条件与排序的组合应用动态排序才是真实业务的常态。比如CRM系统要支持前端自由选择排序字段和方向我的经验是封装一个buildQueryWrapper方法public QueryWrapperCustomer buildQueryWrapper(CustomerQuery query) { QueryWrapperCustomer wrapper new QueryWrapper(); // 动态条件 if (StringUtils.isNotBlank(query.getName())) { wrapper.like(name, query.getName()); } if (query.getMinAge() ! null) { wrapper.ge(age, query.getMinAge()); } // 动态排序 if (balance.equals(query.getSortField())) { wrapper.orderBy(query.isAsc(), true, account_balance); } else if (orders.equals(query.getSortField())) { wrapper.orderBy(query.isAsc(), true, order_count); } return wrapper; }几个实用技巧使用orderBy的布尔参数动态控制升降序建议对前端传入的排序字段做白名单校验复杂条件建议用链式调用保持可读性在数据权限过滤场景中要注意排序字段的可见性。比如部门经理查看员工列表时只能按本部门的字段排序。这时可以在Wrapper中添加过滤条件wrapper.eq(department_id, currentDeptId) .orderByDesc(performance_score);4. 分页查询的排序优化之道分页排序是后台系统的标配但这里藏着不少性能陷阱。在用户行为分析系统中我们遇到过深度分页排序的性能问题// 错误示范 - 性能杀手 PageUser page new Page(10000, 10); queryWrapper.orderByDesc(login_time); userMapper.selectPage(page, wrapper);优化方案有三种方案一使用索引覆盖queryWrapper.select(id, name) // 只查索引字段 .orderByAsc(create_time);方案二延迟关联// 先查ID再关联 PageUser page new Page(1, 10); queryWrapper.select(id).orderByDesc(score); userMapper.selectPage(page, wrapper); ListUser users userMapper.selectBatchIds(page.getRecords());方案三游标分页// 记住上一页最后一条记录的排序值 queryWrapper.gt(create_time, lastCreateTime) .orderByAsc(create_time) .last(limit 10);特别提醒避免在排序字段上使用函数计算如DATE(create_time)大文本字段排序会消耗大量内存分页时一定要有排序条件否则可能出现数据重复在最近的项目中我们对百万级数据采用Elasticsearch做预排序再用MyBatisPlus做精确查询性能提升了20倍。这种混合方案特别适合复杂搜索场景。5. 特殊排序需求的实现方案有些业务需要非常规排序逻辑比如按枚举值的自定义顺序按中文拼音排序按地理距离排序案例按职位级别排序queryWrapper.orderBy(true, false, CASE position WHEN CEO THEN 1 WHEN Manager THEN 2 ELSE 3 END);案例按拼音排序queryWrapper.orderByAsc(CONVERT(name USING gbk));案例按距离排序queryWrapper.select(*, ST_Distance(location, POINT(116.4,39.9)) as distance) .orderByAsc(distance);这些特殊排序要注意数据库方言差异MySQL/Oracle/PG实现不同可能无法使用索引复杂计算建议放在业务层处理在物联网项目中我们遇到过设备状态排序需求在线设备优先相同状态按最后活跃时间倒排 最终用条件构造器实现了多字段组合排序queryWrapper.orderByAsc(CASE WHEN online_status1 THEN 0 ELSE 1 END) .orderByDesc(last_active_time);6. 排序性能监控与优化排序操作可能成为系统瓶颈我有几个实战经验索引策略为常用排序字段创建索引复合索引字段顺序要与排序顺序一致使用explain分析执行计划内存控制// 防止内存溢出 queryWrapper.last(limit 1000);监控方案记录慢查询日志对排序SQL进行采样统计设置执行超时时间在金融项目中我们给排序操作加了熔断机制单次查询超过10万行数据自动终止排序耗时超过3秒降级为简易算法重要报表使用预计算结果的物化视图一个典型优化案例将客户资产排序从实时计算改为定时任务预排序查询速度从5秒提升到200毫秒。关键代码// 每晚跑批更新排序值 Scheduled(cron 0 0 3 * * ?) public void updateUserRanks() { QueryWrapperUser wrapper new QueryWrapper(); wrapper.orderByDesc(total_assets); ListUser users userMapper.selectList(wrapper); int rank 1; for (User user : users) { user.setAssetRank(rank); userMapper.updateById(user); } }7. 测试与异常处理排序逻辑的边界条件特别容易出问题我的测试清单包括空数据集排序包含null值的字段排序超大字段排序并发排序请求null值处理方案// 将null值排在最后 queryWrapper.orderByAsc(ISNULL(score), score);并发测试要点使用CountDownLatch模拟并发检查排序结果的一致性监控数据库连接池使用情况在压力测试中我们发现排序参数注入的风险// 不安全的写法 String sortField request.getParameter(sort); wrapper.orderBy(true, true, sortField); // 可能被SQL注入安全写法应该是// 使用白名单校验 ListString allowedFields Arrays.asList(name, age, create_time); if (allowedFields.contains(sortField)) { wrapper.orderBy(true, true, sortField); }日志排查技巧在Wrapper打印最终SQLlogger.debug(Generated SQL: {}, wrapper.getTargetSql());8. 架构层面的排序思考当系统规模扩大后排序策略需要架构设计支持。在微服务环境中我们采用这些方案缓存排序结果Cacheable(value userRank, key #sortType) public ListUser getUsersWithRank(String sortType) { QueryWrapperUser wrapper new QueryWrapper(); wrapper.orderByDesc(sortType); return userMapper.selectList(wrapper); }分布式排序策略分片排序后归并使用Redis的ZSET结构考虑最终一致性而非实时排序读写分离场景从库可能延迟导致排序不准关键业务强制读主库使用数据库Hint指定数据源在最近的大促准备中我们实现了分级排序策略第一层Redis缓存热数据Top100第二层Elasticsearch处理复杂排序第三层数据库兜底完整数据排序这种组合方案经受住了百万QPS的考验核心代码如下public PageUser getUsersWithSmartSort(Query query) { // 尝试从Redis获取 ListUser cached redisTemplate.opsForZSet() .range(hot_users, 0, -1); if (!cached.isEmpty()) { return new Page(cached); } // 回源查询 QueryWrapperUser wrapper new QueryWrapper(); wrapper.orderBy(true, query.isAsc(), query.getSortField()); return userMapper.selectPage(query.getPage(), wrapper); }