日志分析：通过日志分析，来优化服务器-CSDN博客

本文链接：https://blog.csdn.net/xuukai/article/details/148314938

分析服务器日志，我发现以下潜在异常和需要注意的地方：

1. 频繁的数据库查询

现象：日志中多次出现对 basics_access_config 表的查询操作，且每次查询都返回了相同数量的记录（7条）。例如：

2025-05-29 16:28:51.558 | DEBUG 161236 | http-nio-48084-exec-1 [...] SELECT id, remark, status, role_code, role_code_name, bom_type, field_name, creator_name, updater_name, create_time, update_time, creator, updater, deleted FROM basics_access_config WHERE deleted = 0 AND tenant_id = 185

这类查询在短时间内重复执行了多次（几乎每个请求都会查询此表）。

潜在问题：
- 性能瓶颈：频繁查询相同的数据可能导致数据库压力增大，尤其是在高并发场景下。
- 缓存未命中：如果这些配置数据不经常变化，建议引入缓存机制（如 Redis）来减少数据库访问次数。
改进建议：
- 对静态配置数据（如 basics_access_config）使用缓存，减少重复查询。
- 检查是否有必要在每个请求中都查询该表，优化业务逻辑以减少不必要的数据库访问。

2. 查询条件可能导致数据遗漏

现象：在查询 basics_home_schedule_info 表时，使用了动态参数，但返回了 0 条记录：

2025-05-29 16:28:53.645 | DEBUG 161236 | http-nio-48084-exec-7 [...] SELECT id, content, type, color, participant, participant_name, to_remind, schedule_time, remind_time, creator_name, updater_name, create_time, update_time, creator, updater, deleted FROM basics_home_schedule_info WHERE deleted = 0 AND (create_time BETWEEN ? AND ? AND (FIND_IN_SET(?, participant) OR creator = ?)) AND tenant_id = 185

参数为 2025-05-01T00:00:00.643 到 2025-05-31T23:59:59.643，参与者 ID 为 229，创建者 ID 为 229，但查询结果为空。

潜在问题：
- 查询条件可能过于严格，导致本应返回的数据未被正确检索。
- 数据库中可能确实没有符合条件的数据，但需要进一步确认业务逻辑是否合理。
改进建议：
- 检查数据库中是否存在符合条件的数据。如果数据确实存在，需优化查询条件。
- 如果数据不存在，需确认业务逻辑是否正确（例如，是否应该返回默认值或提示用户无数据）。

3. 更新操作的潜在风险

现象：在更新 basics_purchase_demand 表时，更新了多个字段：

2025-05-29 16:29:10.327 | DEBUG 161236 | http-nio-48084-exec-7 [...] UPDATE basics_purchase_demand SET dept_id = ?, dept_name = ?, demand_no = ?, demand_init = ?, demand_init_name = ?, state = ?, creator_name = ?, updater_name = ?, update_time = ?, updater = ? WHERE id = ? AND deleted = 0 AND tenant_id = 185

参数包含 state = 0，表示需求状态被重置或更新。

潜在问题：
- 如果更新操作未正确处理事务，可能会导致数据不一致。
- 更新条件中使用了 id 和 tenant_id，但未明确是否对并发更新进行了控制（如版本号或时间戳校验）。
改进建议：
- 确保更新操作在事务中执行，避免部分更新成功导致数据不一致。
- 引入乐观锁（如版本号字段）或悲观锁，防止并发更新问题。

4. 日志中未明确记录的异常

现象：日志中未发现明显的异常堆栈（如 ERROR 或 EXCEPTION），但某些操作的耗时较长。例如：
```
2025-05-29 16:29:13.701 | INFO 161236 | http-nio-48084-exec-7 [...] 完成请求 URL(/rpc-api/basics/device-info-api/get-device-list-calibration) 耗时(35 ms)
```
相较于其他耗时较短的请求（如 2-3ms），该请求耗时 35ms，可能需要进一步分析。
潜在问题：
- 耗时较长的操作可能涉及复杂的查询或业务逻辑，需确认是否有必要优化。
改进建议：
- 对耗时较长的接口进行性能分析，检查是否存在 SQL 查询效率低下或业务逻辑可优化的地方。
- 使用数据库查询分析工具（如 MySQL 的 EXPLAIN）检查慢查询。

5. 未使用分页或限制参数的查询

现象：某些查询未明确使用分页或限制返回记录数，例如：

2025-05-29 16:29:13.729 | DEBUG 161236 | http-nio-48084-exec-3 [...] SELECT id, room_bom, room_bom_id, [...] FROM basics_room_information WHERE id = ? AND deleted = 0 AND tenant_id = 185

该查询返回了 1 条记录，但如果 id 参数不存在或查询条件放宽，可能会返回大量数据。

潜在问题：
- 如果查询未使用分页或限制，可能在数据量较大时导致性能问题或内存溢出。
改进建议：
- 对所有查询操作明确添加分页参数（如 LIMIT）或记录数限制，避免一次性返回过多数据。

6. 重复的请求和处理

现象：日志中多次出现相同的请求 URL 和参数，例如：

2025-05-29 16:29:10.398 | INFO 161236 | http-nio-48084-exec-9 [...] 完成请求 URL(/admin-api/basics/material-bom/page) 耗时(20 ms)
2025-05-29 16:29:12.054 | INFO 161236 | http-nio-48084-exec-4 [...] 完成请求 URL(/admin-api/basics/material-bom/page) 耗时(3 ms)

同一接口在短时间内被多次调用，且参数相似。