Question

使用SQL Server 2005.我在一个有大约200k记录的表上做了一些简单的查询。截至今天，当我开始工作时，一个简单的SELECT * FROM执行，直到它检索到大约20k行...然后停止。它不会超过20k行。如果我在使用ORDER BY Created DESC时尝试仅选择一行，则查询将无限期运行。我以前从未遇到过这个。所有其他表格都正常运作。我的桌子可能已经损坏了吗？这真的是一夜之间发生的。该表确实采用了实时数据，但一直这样做（通过表格）几个月没有问题。可能是一些错误的记录破坏了查询吗？如果是这样，我怎么能找到它...因为我再也找不到结果了？

如果这很模糊，我道歉，但我不确定该怎么说。

Answer 1

SET ROWCOUNT是否已应用于您的会话？

Answer 2

SELECT COUNT（*）会返回任何内容吗？它是否准确（例如大约200k）？需要多长时间？

您应该尝试对数据库执行完整备份，然后还原到新的数据库名称。之后，查看您是否遇到与已还原数据库相同的问题。

Answer 3

DBCC CHECKTABLE可用于检查单个表及其索引的完整性。

'SET ROWCOUNT'似乎是最可能的罪魁祸首，但可能你不是故意设置它。可能会以某种方式在后台为您设置此值/设置;它可以在SSMS中设置以应用于所有窗口（工具/选项/查询执行），甚至只应用于当前窗口（查询/查询选项/执行）。

存在其他（而且，坦白，荒谬）的可能性。通过SQL事件探查器跟踪您的会话（从登录到提交的查询）可能会显示更多更微妙的信息。

Answer 4

我认为未提交的事务会对至少一个与SELECT查询所需的共享锁不兼容的行或页面进行锁定。

要解决此问题，您可以在一个SSMS窗口中执行失败的SELECT ...查询。

然后在第二个窗口中，当第一个查询仍在执行时，阻止运行the following script。

这应该会向您显示有问题的SQL以及对其进行故障排除的足够详细信息。

SELECT Blocking.session_id          AS BlockingSessionId,
       Sess.login_name              AS BlockingUser,
       BlockingSQL.text             AS BlockingSQL,
       Waits.wait_type              WhyBlocked,
       Blocked.session_id           AS BlockedSessionId,
       USER_NAME(Blocked.user_id)   AS BlockedUser,
       BlockedSQL.text              AS BlockedSQL,
       DB_NAME(Blocked.database_id) AS DatabaseName
FROM   sys.dm_exec_connections AS Blocking
       INNER JOIN sys.dm_exec_requests AS Blocked
         ON Blocking.session_id = Blocked.blocking_session_id
       INNER JOIN sys.dm_os_waiting_tasks AS Waits
         ON Blocked.session_id = Waits.session_id
       RIGHT OUTER JOIN sys.dm_exec_sessions Sess
         ON Blocking.session_id = Sess.session_id
       CROSS APPLY sys.dm_exec_sql_text(Blocking.most_recent_sql_handle) AS BlockingSQL
       CROSS APPLY sys.dm_exec_sql_text(Blocked.sql_handle) AS BlockedSQL
ORDER  BY BlockingSessionId,
          BlockedSessionId

SQL Server中的表不会返回超过几千行

4 个答案: