已超过了锁请求超时时段。 (Microsoft SQL Server，错误: 1222)

如果一开始就知道是这样的问题，找度娘和谷哥不就完了。

他们明明白白会告诉你，就这……就是有死锁了，干死就完了。

-- 第一步：查询死锁
select    
    request_session_id spid,   
    OBJECT_NAME(resource_associated_entity_id) tableName    
from    
    sys.dm_tran_locks   
where    
    resource_type='OBJECT'

----第二步，杀死kill spid
--例如
kill 354

当然，得多观察会，说不定是短死锁，等一下就消失了。

或者执行如下语句：

SELECT blocking_session_id '阻塞进程的ID', wait_duration_ms '等待时间(毫秒)', session_id '(会话ID)' FROM sys.dm_os_waiting_tasks

如果阻塞进程的id有值，可以杀死。

不过曲折的过程，我觉得有必要分享下，给大家提供个解决问题的思路。

今天是其他项目组负责人找到我，说让我帮忙还原个他们生产库，说是可能服务器有问题了，最近访问慢。

我问都做了哪些努力，说是最近一直有问题，所以扩了内存什么的还是慢。

我说扩内存不太对吧，是不是代码开发的问题，没建索引什么的慢，是不是有死锁什么的。负责人斩钉截铁的说，这些都查过了，别想软件的事，肯定是数据库服务器的事。

上来就祭出运维三板斧：重启、重装、换机器。。。。这，粗暴了点吧。

于是我让他们的开发按照重建索引的思路去做，心想既然是都试过了，说不定服务器异常宕机，索引有碎片了。

他们执行了一半，系统也没什么起色，于是我好奇的上去看了看，发现本机查询数据库是不慢的，而客户端连接就有些慢。我有些求姐不得。

于是搜了下度娘，SqlServer本机连接不慢，客户端慢什么原因。也没差个所以然。不过还是发现了一个重要线索，发现客户端加载数据库，点击显示所有表的时候，一直转圈出不来。

这个问题有点似曾相识，我记得曾经出现这个问题，是数据库某种资源达到了极限，所以我首先怀疑是数据库日志设定了上限，而且满了。

于是乎，我爬到数据库服务器上看了看，点了属性的时候，就报出了文中开始出现的错误。

这一下载就让人激动了，按图索骥，果然让我找到一个死锁的进程id号。杀死以后，客户端加载表也正常了，查询也正常了。

安全起见，发现他们的数据库日志已经膨胀到了5G，给粗暴的减了个肥。

看来不用耍三板斧了，得杀个程序猿祭祭天：）