1. 问题诊断为什么消息积压会让登录变慢最近遇到不少用友U8用户反馈客户端登录时特别慢有时候要等好几分钟才能进去。作为系统管理员我第一反应就是去查数据库性能。果然打开UFSystem数据库一看UA_Message表里堆积了20多万条消息记录。这就像快递站堆满了未处理的包裹新包裹进来时找位置都困难。消息表积压影响登录速度的原理很简单每次用户登录时系统都要检查该用户是否有未读消息。当UA_Message表数据量过大时这个查询操作就会变得非常耗时。特别是如果没有合适的索引数据库就得全表扫描相当于要在堆积如山的文件中逐页翻找。我常用的排查步骤是先用SELECT COUNT(*) FROM UA_Message查看消息总量执行sp_who2观察登录时的数据库会话状态通过SQL Server Profiler抓取登录过程的详细查询实测发现当消息超过10万条时登录响应时间就开始明显上升。有个客户的案例特别典型清理前平均登录耗时47秒清理后直接降到3秒内。所以定期维护这个消息表非常必要。2. 安全清理三步搞定历史消息2.1 备份是重中之重直接删除生产环境数据就像高空作业不系安全带。我建议先用这个脚本创建备份表-- 创建按日期命名的备份表 SELECT * INTO UA_Message_Bak_20230815 FROM UA_Message -- 验证备份数据量 SELECT COUNT(*) FROM UA_Message_Bak_20230815有次我遇到个惨痛教训客户要求清理3个月前的数据结果误删了重要审批消息。幸好有备份表最后用INSERT INTO UA_Message SELECT * FROM UA_Message_Bak_20230301 WHERE ...恢复了关键数据。所以现在我都养成习惯备份表至少保留1个月。2.2 条件删除的注意事项清理消息不是简单的DELETE FROM UA_Message要考虑业务需求。我推荐保留最近15天的数据-- 标准清理脚本保留15天 DELETE FROM UA_Message WHERE datediff(day, dSend, getdate()) 15 -- 带事务的回滚方案 BEGIN TRANSACTION DELETE FROM UA_Message WHERE datediff(month, dSend, getdate()) 2 -- 确认删除条数后再COMMIT或ROLLBACK特别注意大表删除建议分批进行避免锁表可以先SELECT COUNT预估删除量生产环境务必在非高峰时段操作2.3 清理后的统计信息更新很多管理员忽略这一步其实特别重要-- 更新该表的统计信息 UPDATE STATISTICS UA_Message -- 重建表索引 DBCC DBREINDEX(UA_Message)有次清理后登录速度没改善查了半天发现是统计信息过期导致执行计划错误。后来我养成了习惯任何数据变更后都立即更新统计信息。3. 系统性优化治标更要治本3.1 索引优化实战UA_Message表通常需要这些索引-- 登录查询常用索引 CREATE INDEX IX_UA_Message_Reciver ON UA_Message(cReciver) INCLUDE (cTitle, dSend, bRead) -- 时间范围查询索引 CREATE INDEX IX_UA_Message_dSend ON UA_Message(dSend)建议用这个脚本检查索引碎片SELECT OBJECT_NAME(ind.OBJECT_ID) AS TableName, ind.name AS IndexName, indexstats.avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats INNER JOIN sys.indexes ind ON ind.object_id indexstats.object_id WHERE OBJECT_NAME(ind.OBJECT_ID) UA_Message AND indexstats.avg_fragmentation_in_percent 303.2 自动化维护方案手工维护太麻烦我推荐创建定期作业-- 每周自动清理的存储过程 CREATE PROCEDURE sp_AutoCleanMessage AS BEGIN -- 备份2个月前的数据 DECLARE BackupTableName NVARCHAR(100) SET BackupTableName UA_Message_Bak_ CONVERT(VARCHAR(8), GETDATE(), 112) EXEC(SELECT * INTO BackupTableName FROM UA_Message WHERE datediff(month, dSend, getdate()) 2) -- 清理旧数据 DELETE FROM UA_Message WHERE datediff(month, dSend, getdate()) 2 -- 维护索引 DBCC DBREINDEX(UA_Message) UPDATE STATISTICS UA_Message END可以配合SQL Server Agent设置为每月1号凌晨执行。有个客户实施后再没出现过登录卡顿的投诉。3.3 监控预警机制预防胜于治疗我习惯配置这些监控表空间监控设置UA_Message表增长超过1GB时告警查询耗时监控捕获执行时间超过5秒的登录相关查询定期健康检查每周自动生成索引碎片报告用这个查询可以监控消息增长趋势-- 按月统计消息量 SELECT CONVERT(VARCHAR(7), dSend, 120) AS Month, COUNT(*) AS MessageCount FROM UA_Message GROUP BY CONVERT(VARCHAR(7), dSend, 120) ORDER BY Month DESC4. 疑难问题排查指南4.1 清理后速度没改善遇到过几次清理后效果不明显的情况后来总结出这些排查点检查是否有未提交的长事务阻塞确认统计信息是否及时更新查看执行计划是否走错索引检查网络延迟或客户端配置问题有个案例特别有意思清理后速度反而变慢了。最后发现是查询优化器选了不合适的执行计划用UPDATE STATISTICS WITH FULLSCAN解决了问题。4.2 大表删除的技巧当需要清理百万级数据时我推荐分批删除WHILE 11 BEGIN DELETE TOP (5000) FROM UA_Message WHERE datediff(month, dSend, getdate()) 6 IF ROWCOUNT 0 BREAK WAITFOR DELAY 00:00:01 -- 每批间隔1秒 END这样既避免锁表太久又给日志文件喘息时间。曾经用这个方法在业务高峰期平稳清理了800万条记录。4.3 特殊业务场景处理有些客户的审批流程必须永久保存消息记录。我的解决方案是创建归档数据库定期转移历史数据修改登录查询逻辑不检查超过1年的消息使用过滤索引优化近期数据查询例如这个归档方案-- 每年初执行归档 INSERT INTO ArchiveDB..UA_Message_History SELECT * FROM UA_Message WHERE dSend DATEADD(year, -1, GETDATE()) DELETE FROM UA_Message WHERE dSend DATEADD(year, -1, GETDATE())记住任何优化方案都要先和业务部门确认需求。有次我自作主张改了保留策略结果把财务的年结消息给清理了教训深刻啊