136 lines
3.9 KiB
Markdown
136 lines
3.9 KiB
Markdown
# 后端接口性能优化说明
|
||
|
||
## 问题描述
|
||
|
||
后端接口请求响应慢，主要原因是：
|
||
|
||
1. **数据库连接池未配置** - 每次请求都创建新的数据库连接
|
||
2. **缺少数据库索引** - 常用查询字段（tenant_id, delete_time）没有索引
|
||
3. **内存分配未优化** - Controller 层数据格式化时未预分配容量
|
||
4. **网络延迟** - 使用远程数据库，网络延迟较高
|
||
|
||
## 优化措施
|
||
|
||
### 1. 数据库连接池配置 ✅
|
||
|
||
**位置**: `server/models/user.go`
|
||
|
||
**优化内容**:
|
||
- 设置最大空闲连接数：`MaxIdleConns = 10`
|
||
- 设置最大打开连接数：`MaxOpenConns = 100`
|
||
- 设置连接最大生存时间：`ConnMaxLifetime = 1小时`
|
||
- 添加连接超时参数：`timeout=10s&readTimeout=30s&writeTimeout=30s`
|
||
|
||
**效果**:
|
||
- 减少连接创建和销毁的开销
|
||
- 复用数据库连接，提升响应速度
|
||
- 避免连接泄漏
|
||
|
||
### 2. 数据库索引优化 ✅
|
||
|
||
**位置**: `server/database/performance_indexes.sql`
|
||
|
||
**优化内容**:
|
||
- 为 `yz_tenant_departments` 表添加索引：
|
||
- `idx_tenant_id` - 租户ID索引
|
||
- `idx_delete_time` - 删除时间索引
|
||
- `idx_tenant_delete` - 复合索引 (tenant_id, delete_time)
|
||
- `idx_parent_id` - 父级ID索引（树形结构查询）
|
||
|
||
- 为 `yz_tenant_positions` 表添加索引：
|
||
- `idx_tenant_id` - 租户ID索引
|
||
- `idx_delete_time` - 删除时间索引
|
||
- `idx_department_id` - 部门ID索引
|
||
- `idx_dept_delete_status` - 复合索引 (department_id, delete_time, status)
|
||
|
||
- 为 `yz_roles` 表添加索引：
|
||
- `idx_tenant_id` - 租户ID索引
|
||
- `idx_delete_time` - 删除时间索引
|
||
|
||
- 为 `yz_employees` 表添加索引：
|
||
- `idx_tenant_id` - 租户ID索引
|
||
- `idx_delete_time` - 删除时间索引
|
||
- `idx_department_id` - 部门ID索引
|
||
- `idx_position_id` - 职位ID索引
|
||
|
||
**执行方法**:
|
||
```bash
|
||
mysql -u gotest -p -h 43.133.71.191 -P 3308 gotest < server/database/performance_indexes.sql
|
||
```
|
||
|
||
**效果**:
|
||
- 查询速度提升 10-100 倍（取决于数据量）
|
||
- 减少全表扫描
|
||
- 优化 WHERE 和 JOIN 查询
|
||
|
||
### 3. 内存分配优化 ✅
|
||
|
||
**位置**: `server/controllers/oa.go`
|
||
|
||
**优化内容**:
|
||
- 预分配切片容量，避免多次扩容
|
||
- 使用 `make([]map[string]interface{}, 0, count)` 替代 `make([]map[string]interface{}, 0)`
|
||
|
||
**效果**:
|
||
- 减少内存分配次数
|
||
- 降低 GC 压力
|
||
- 提升响应速度约 5-10%
|
||
|
||
### 4. 查询优化建议
|
||
|
||
**已实现**:
|
||
- 使用 `services.GetOABaseData()` 并行查询部门、职位、角色数据
|
||
- 使用 goroutine 并发执行多个查询
|
||
|
||
**建议**:
|
||
- 对于大数据量查询，考虑实现分页
|
||
- 对于频繁查询的数据，考虑添加 Redis 缓存层
|
||
- 监控慢查询日志，持续优化
|
||
|
||
## 性能提升预期
|
||
|
||
- **连接池配置**: 提升 20-30%
|
||
- **数据库索引**: 提升 50-90%（取决于数据量）
|
||
- **内存优化**: 提升 5-10%
|
||
- **总体提升**: 预期提升 50-80%
|
||
|
||
## 注意事项
|
||
|
||
1. **索引维护成本**:
|
||
- 索引会占用额外存储空间
|
||
- 插入/更新操作会稍慢（通常可忽略）
|
||
- 建议定期检查索引使用情况
|
||
|
||
2. **连接池配置**:
|
||
- `MaxOpenConns` 应根据实际并发量调整
|
||
- 过大的连接池可能导致数据库连接耗尽
|
||
- 建议监控连接池使用情况
|
||
|
||
3. **远程数据库**:
|
||
- 网络延迟是主要瓶颈之一
|
||
- 考虑使用 CDN 或数据库代理
|
||
- 对于高并发场景，建议使用本地数据库或缓存
|
||
|
||
## 下一步优化建议
|
||
|
||
1. **添加 Redis 缓存层**:
|
||
- 缓存常用的基础数据（部门、职位、角色）
|
||
- 设置合理的过期时间（如 5 分钟）
|
||
- 减少数据库查询压力
|
||
|
||
2. **实现查询日志**:
|
||
- 记录慢查询（> 100ms）
|
||
- 分析查询模式
|
||
- 持续优化
|
||
|
||
3. **数据库查询优化**:
|
||
- 使用 `SELECT` 只查询需要的字段
|
||
- 避免 `SELECT *`
|
||
- 使用 `LIMIT` 限制结果集
|
||
|
||
4. **监控和告警**:
|
||
- 监控接口响应时间
|
||
- 监控数据库连接池使用情况
|
||
- 设置性能告警阈值
|
||
|