系统环境：金蝶云星空企业版V7.X，数据库sqlswerver 2012R2，业务数据库200G左右

服务器两台：一台应用服务器，一台数据库服务器，两台内存均为64G，日常库存占用率90%左右。

       首先，了解到库存管理的即时库存查询和物料收发明细表等大数据查询都没有问题，出入库单据审核及查询也是正常的。因此大概率排除了系统环境和服务器硬件资源不足问题，初步判断是数据库中某个表出现了长时间死锁现象，从而导致了系统超时报错。
       本着遇事先问论坛的原则，在论坛搜索到官方知识“如何排查数据库死锁问题https://wenku.my7c.com/questions/135435095930145083/answers/135435142134597993”，使用帖子里的sql脚本查数据库的死锁情况：

SELECT XEvent.query('(event/data/value/deadlock)[1]') AS DeadlockGraph

FROM (

SELECT XEvent.query('.') AS XEvent

FROM (

SELECT CAST(target_data AS XML) AS TargetData

FROM sys.dm_xe_session_targets st

INNER JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address

WHERE s.NAME = 'system_health'

AND st.target_name = 'ring_buffer'

) AS Data

CROSS APPLY TargetData.nodes('RingBufferTarget/event[@name=xml_deadlock_report]') AS XEventData(XEvent)

) AS source

      令人尴尬的是，查询后没有发现被死锁的表。于是采用了“重启大法”，在使用管理员登录清理了冲突操作，清理缓存后，分别对应用服务器重启了iis，数据库服务器也重启了sqlserver服务。然而....问题依旧！

     于是不死心从百度搜索“SQLSERVER死锁”，找到一篇帖子将如何找到死锁表的sql语句：

SELECT request_session_id spid,OBJECT_NAME(resource_associated_entity_id)tableName 

FROM sys.dm_tran_locks 

WHERE resource_type='OBJECT ' 

       这次返回的查询结果中有一行赫然显示：

    由此确定了还是有死锁，通过SQL查询分析器执行: "kill 90"强制解锁后，再次进星空运行库存校对，结果涛声依旧。看来t_stk_invbal（库存余额表）还是有问题，在查询分析器通过执行：“dbcc  checktable('t_stk_invbal') ”对表进行扫描，经过几分钟后结果显示表是正常的，表中的数据行数接近1000万行，但是没有扫出任何错误。

    再次对现象进行剖析，结合系统逻辑进行分析，库存校对前，应该会先到t_stk_invbal（库存余额表）获取期初库存数据，然后再对当前期间的库存单据重新进行运算得到新的库存，并更新到库存表。如果第一步超时了，那后续的动作应该也是会超时。围绕“大数据量表，查询超时”两个关键点思考，突然灵光一现，该不会是表索引问题吧。因此在SQL维护计划中对该表单独创建了一个维护计划，计划的内容主要是重建索引及更新该表的统计信息。

     执行完该维护计划后，进入星空，运行库存校对，2分钟后系统提示库存校对成功，至此问题解决！对此次问题处理的经验总结：大数据表在经过大量数据写入或修改、删除后，应及时进行重建索引，否则很容易造成数据查询超时！

当然查询数据库表被锁定还可以通过数据库的标准报表“按对象排列的资源锁定统计信息”查看：