GLPI项目用户管理界面性能优化分析

问题背景

在使用GLPI 10.0.18版本时，管理员访问用户列表页面出现了严重的性能问题，加载时间长达4分钟。通过分析MariaDB的慢查询日志，发现一个查询语句扫描了惊人的1.81亿行数据，导致系统响应缓慢。

技术分析

查询性能瓶颈

核心问题出现在用户列表页面的SQL查询语句上，该查询主要存在以下性能问题：

1. 数据扫描量过大：查询扫描了1.81亿行数据，而实际用户数只有280个
2. 复杂连接操作：查询涉及7张表的连接操作，包括用户表、配置表、邮件表、位置表、LDAP认证表以及两张工单表
3. 聚合函数使用：使用了GROUP_CONCAT和COUNT等聚合函数，增加了计算开销
4. 临时表生成：查询过程中生成了5个临时表，其中1个存储在磁盘上

关键影响因素

查询中特别值得注意的是对工单表的连接操作：

1. 工单数量影响：系统中有13,000个工单记录
2. 统计字段影响：查询中包含"作为请求者的工单数"和"作为处理者的工单数"两个统计字段

解决方案

临时解决方案

1. 移除统计字段：从用户列表显示列中移除"作为请求者的工单数"和"作为处理者的工单数"两个统计字段
2. 验证效果：移除后查询性能显著提升，页面加载时间恢复正常

长期优化建议

1. 查询重构：

   • 考虑将统计信息查询与基本信息查询分离
   • 使用延迟加载技术，只在用户点击查看详情时加载统计信息

2. 索引优化：

   • 确保用户ID、工单关联表上的相关字段都有适当索引
   • 考虑为常用查询条件创建复合索引

3. 缓存策略：

   • 对统计信息实施缓存机制，减少实时计算
   • 设置合理的缓存过期时间

4. 分页优化：

   • 确保分页查询在获取第一页数据时不会扫描全部结果集

最佳实践

对于GLPI系统管理员，建议：

1. 精简列表显示字段：只保留最常用的字段，减少查询复杂度
2. 定期维护数据库：执行表优化和索引重建
3. 监控系统性能：定期检查慢查询日志，及时发现性能问题
4. 合理使用统计功能：在需要时才查看统计信息，避免在列表页面显示

总结

GLPI用户管理界面的性能问题主要源于复杂的关联查询和实时统计计算。通过优化查询结构、合理配置显示字段和实施缓存策略，可以显著提升系统响应速度。对于大型部署环境，建议特别注意统计功能的性能影响，并根据实际需求进行适当调整。