ljwx-health/backup_docs_20260104_182653/ADMIN_USER_QUERY_OPTIMIZATION_ANALYSIS.md

管理员查询逻辑优化分析报告

📊 优化概述

本次优化主要针对 sys_user 表的管理员查询逻辑进行了全面重构，重点解决了性能瓶颈和查询效率问题。

🔍 原始实现分析

原始代码问题

文件位置: ljwx-boot/ljwx-boot-modules/src/main/java/com/ljwx/modules/system/service/impl/SysUserServiceImpl.java

1. 管理员判断的性能问题

// 原始代码 - 性能瓶颈
List<SysUser> filteredUsers = allUsers.stream()
    .filter(user -> {
        boolean isAdmin = isAdminUser(user.getId()); // ❌ 每个用户都执行一次数据库查询
        return !isAdmin;
    })
    .collect(Collectors.toList());

问题分析:

• 对每个用户执行 isAdminUser(user.getId()) 方法
• isAdminUser() 方法内部执行 this.getById(userId) 查询单个用户
• 性能影响: 如果查询100个用户，需要执行101次数据库查询（1次批量查询 + 100次单个查询）

2. 组织层级查询效率问题

// 原始代码 - 复杂的递归查询
List<SysOrgUnits> descendants = sysOrgUnitsService.listAllDescendants(Collections.singletonList(orgId));
List<SysUser> allUsers = baseMapper.getUsersByOrgIds(orgIds);

问题分析:

• 没有使用优化的组织闭包表
• 递归查询效率较低
• 缺少缓存机制

🚀 优化方案实施

1. 基于 user_type 字段的管理员过滤

优化前 (N+1 查询问题)

// 每个用户都要单独查询数据库判断是否管理员
.filter(user -> {
    boolean isAdmin = isAdminUser(user.getId()); // 单独SQL查询
    return !isAdmin;
})

数据库查询次数: 1 + N (N为用户数量)

优化后 (单次SQL完成)

// 直接在SQL中过滤，一次查询完成
LambdaQueryWrapper<SysUser> queryWrapper = new LambdaQueryWrapper<SysUser>()
    .in(SysUser::getOrgId, orgIds)
    .eq(SysUser::getCustomerId, customerId)
    .and(wrapper -> wrapper
        .isNull(SysUser::getUserType)  // user_type 为 null
        .or()
        .eq(SysUser::getUserType, 0)   // 或者 user_type = 0 (普通用户)
    );

数据库查询次数: 1 (仅一次查询)

2. 使用组织闭包表优化层级查询

优化前

// 使用递归查询，效率较低
List<SysOrgUnits> descendants = sysOrgUnitsService.listAllDescendants(Collections.singletonList(orgId));

优化后

// 使用高效的闭包表，带缓存
List<SysOrgUnits> descendants = sysOrgClosureService.findAllDescendants(orgId, customerId);

优势:

• 使用 sys_org_closure 闭包表，预计算组织层级关系
• 内置 @Cacheable 缓存机制
• 性能监控和日志记录

3. 接口方法重构

新增优化的接口方法

// 核心方法：仅查询普通用户
List<SysUser> getUsersByOrgId(Long orgId, Long customerId);

// 扩展方法：查询所有用户（包含管理员）
List<SysUser> getAllUsersByOrgId(Long orgId, Long customerId);

// 灵活方法：按用户类型查询
List<SysUser> getUsersByOrgIdAndUserType(Long orgId, Long customerId, Integer userType);

📈 性能提升分析

数据库查询次数对比

场景	用户数量	优化前查询次数	优化后查询次数	性能提升
小型组织	10人	11次 (1+10)	1次	91% 减少
中型组织	50人	51次 (1+50)	1次	98% 减少
大型组织	200人	201次 (1+200)	1次	99.5% 减少

SQL执行效率对比

优化前的SQL执行

-- 第1次：批量查询用户
SELECT * FROM sys_user WHERE org_id IN (1,2,3,4,5);

-- 第2-N次：逐个查询用户判断管理员身份
SELECT * FROM sys_user WHERE id = 1;
SELECT * FROM sys_user WHERE id = 2;
SELECT * FROM sys_user WHERE id = 3;
-- ... 重复N次

优化后的SQL执行

-- 仅1次：直接过滤查询
SELECT * FROM sys_user 
WHERE org_id IN (1,2,3,4,5) 
  AND customer_id = 123 
  AND (user_type IS NULL OR user_type = 0);

网络开销分析

指标	优化前	优化后	改善
数据库连接次数	N+1	1	减少 99%+
网络往返次数	N+1	1	减少 99%+
数据传输量	高	低	显著减少

🔧 代码质量提升

1. 类型安全和参数校验

// 添加了完整的异常处理
try {
    // 业务逻辑
    return users;
} catch (Exception e) {
    long endTime = System.currentTimeMillis();
    log.error("❌ getUsersByOrgId 执行失败，耗时: {}ms", endTime - startTime, e);
    throw new BizException("查询组织用户失败: " + e.getMessage());
}

2. 性能监控和日志

long startTime = System.currentTimeMillis();
// ... 业务处理 ...
long endTime = System.currentTimeMillis();
log.info("✅ 从数据库查询到的普通用户数量: {}, 耗时: {}ms", users.size(), endTime - startTime);

3. 清晰的方法职责分离

• getUsersByOrgId(): 仅查询普通用户
• getAllUsersByOrgId(): 查询所有用户
• getUsersByOrgIdAndUserType(): 按类型查询用户

🎯 业务逻辑优化

用户类型定义标准化

/**
 * 用户类型枚举
 * 0 = 普通用户
 * 1 = 部门管理员  
 * 2 = 租户管理员
 * 3 = 超级管理员
 */

组织架构查询优化

• 利用 sys_org_closure 闭包表的预计算优势
• 支持缓存机制，减少重复查询
• 精确的租户隔离 (customerId)

⚡ 预期性能提升

响应时间改善

• 小型查询 (10-50用户): 从 200-500ms 降至 10-50ms
• 中型查询 (50-200用户): 从 500ms-2s 降至 50-200ms
• 大型查询 (200+用户): 从 2s+ 降至 200ms内

数据库负载减轻

• 查询频率降低 90%+
• 连接池压力显著减少
• 并发处理能力大幅提升

内存使用优化

• 减少冗余对象创建
• 降低 GC 压力
• 更高效的数据流处理

🧪 测试建议

1. 功能测试

# 测试普通用户查询
GET /sys_user/get_users_by_org_id?orgId=1939964806110937090&customerId=0

# 测试管理员过滤是否正确
# 验证返回的用户都是 user_type = 0 或 null

2. 性能测试

• 对比优化前后的响应时间
• 监控数据库查询日志
• 压力测试并发查询能力

3. 边界条件测试

• 空组织测试
• 大量用户组织测试
• 深层级组织结构测试

📋 部署注意事项

1. 数据库要求

确保以下字段和索引存在：

-- sys_user 表必需字段
ALTER TABLE sys_user ADD COLUMN user_type INT DEFAULT 0 COMMENT '用户类型';
ALTER TABLE sys_user ADD COLUMN customer_id BIGINT COMMENT '租户ID';

-- 性能优化索引
CREATE INDEX idx_user_org_customer_type ON sys_user(org_id, customer_id, user_type);
CREATE INDEX idx_user_customer_type ON sys_user(customer_id, user_type);

2. 接口兼容性

• 新接口增加了 customerId 参数
• 前端调用需要相应更新
• 建议先保持向后兼容，逐步迁移

🎉 优化总结

本次管理员查询逻辑优化实现了：

✅ 性能提升 90%+: 从N+1查询优化到单次查询
✅ 代码质量提升: 清晰的职责分离和异常处理
✅ 可维护性提升: 标准化的用户类型管理
✅ 可扩展性提升: 灵活的查询接口设计
✅ 监控能力提升: 完整的性能日志和错误追踪

这次优化不仅解决了当前的性能问题，还为未来的功能扩展奠定了良好的基础。