kknongchang_2506/AiWork/2025年06月/07日1744-优化用户日志清理逻辑.md

优化用户日志清理逻辑

任务时间：2025年06月07日 17:44
任务类型：功能优化
模块：Game模块 - 用户日志系统

任务概述

优化用户日志清理逻辑，创建一个数据库表记录清理时间，进行逻辑清理，只返回该用户清理之后的日志给用户；真实的日志清理会影响日志的收集备份工作。

问题分析

原有问题

1. 物理删除影响备份：原来的清理逻辑直接删除数据库中的日志记录，影响日志收集和备份工作
2. 数据不可恢复：一旦删除，用户的历史日志无法恢复
3. 性能影响：大量删除操作对数据库性能有影响

解决方案

实现逻辑清理机制：

• 创建清理记录表记录用户的清理时间
• 查询时只返回清理时间之后的日志
• 保留所有实际日志数据

实现内容

1. 数据库设计

新增表：kku_user_log_clear_records

CREATE TABLE `kku_user_log_clear_records` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `user_id` int NOT NULL COMMENT '用户ID',
  `cleared_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '清理时间',
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_user_id` (`user_id`),
  KEY `idx_cleared_at` (`cleared_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户日志清理记录表';

2. 模型层

新增文件：app/Module/Game/Models/UserLogClearRecord.php

• 实现用户清理记录的基本CRUD操作
• 提供静态方法获取和设置用户清理时间
• 支持按用户查询作用域

3. 逻辑层修改

修改文件：app/Module/Game/Logics/UserLogLogic.php

• clearUserLogs() 方法：改为记录清理时间而非删除日志
• getUserLogs() 方法：添加清理时间过滤，只返回清理后的日志
• getUserLogStats() 方法：统计时考虑清理时间
• hasUserLogs() 和 getLatestUserLogs() 方法：同样考虑清理时间

4. 后台管理

新增文件：app/Module/Game/AdminControllers/UserLogClearRecordController.php

• 提供清理记录的查看功能
• 禁用创建、编辑、删除操作（只读）
• 支持按用户ID和时间范围过滤

新增文件：app/Module/Game/Repositories/UserLogClearRecordRepository.php

• 为后台管理提供数据访问服务
• 提供统计和查询方法

5. 测试验证

新增文件：app/Module/Game/Commands/TestUserLogClearCommand.php

• 提供完整的测试流程
• 验证清理前后的日志数量变化
• 确认实际日志数据未被删除

技术实现细节

逻辑清理流程

1. 用户点击清理日志
2. 系统记录当前时间到清理记录表
3. 后续查询只返回清理时间之后的日志
4. 实际日志数据保持完整

查询优化

• 在查询用户日志时添加时间过滤条件
• 使用索引优化查询性能
• 保持API接口不变，对上层透明

数据一致性

• 使用唯一索引确保每个用户只有一条清理记录
• 支持更新清理时间（多次清理）
• 事务保证操作的原子性

测试结果

功能测试

=== 用户日志清理逻辑测试 ===

1. 查看用户 10001 当前可见的日志数量:
   可见日志总数: 264
   当前页日志数: 10

2. 查看用户的清理记录:
   最后清理时间: 2025-06-07 16:47:58

3. 执行清理操作:
   清理成功

4. 查看清理后的日志数量:
   可见日志总数: 0
   当前页日志数: 0

5. 查看新的清理记录:
   最后清理时间: 2025-06-07 17:50:02

6. 验证数据库中的实际日志数量:
   数据库中实际日志总数: 928
   说明: 实际日志没有被删除，只是逻辑上被隐藏

新日志测试

• 清理后添加新日志正常显示
• 再次清理后新日志也被隐藏
• 数据库中日志总数持续增长

优势总结

✅ 用户体验

• 用户看到的效果与物理删除一致
• 清理操作响应速度快
• 支持多次清理操作

✅ 数据安全

• 实际日志数据完全保留
• 支持数据恢复（如需要）
• 不影响日志收集和备份工作

✅ 性能优化

• 避免大量删除操作
• 查询时使用索引优化
• 减少数据库锁定时间

✅ 系统稳定性

• 不影响现有API接口
• 日志收集系统正常运行
• 备份工作不受影响

相关文件

新增文件

• app/Module/Game/Models/UserLogClearRecord.php
• app/Module/Game/AdminControllers/UserLogClearRecordController.php
• app/Module/Game/Repositories/UserLogClearRecordRepository.php
• app/Module/Game/Commands/TestUserLogClearCommand.php
• app/Module/Game/Databases/GenerateSql/user_log_clear_records.sql

修改文件

• app/Module/Game/Logics/UserLogLogic.php
• app/Module/Game/Providers/GameServiceProvider.php
• app/Module/Game/Databases/README.md

后续建议

1. 监控清理记录：定期检查清理记录表的数据增长
2. 性能监控：关注查询性能，必要时优化索引
3. 数据清理策略：考虑定期清理过期的实际日志数据
4. 用户反馈：收集用户对新清理机制的反馈

总结

本次优化成功实现了用户日志的逻辑清理机制，在保证用户体验的同时，确保了数据的完整性和系统的稳定性。通过创建清理记录表和修改查询逻辑，避免了物理删除对日志收集备份工作的影响，是一个既实用又安全的解决方案。