如果我首先在 SSMS 中运行相同的查询，则该查询可以在 C# 程序中运行（无超时）。在我在 SSMS 中运行查询之前，数据库似乎尚未初始化、加载等。
仅当数据库刚刚恢复或恢复数据库快照时才会发生这种情况。如果服务器/数据库重新启动等也会发生同样的情况
该查询有些复杂，有五个临时表以及这些临时表的联接以及其他三个带有许多 where 子句的表联接。同样，查询有效，因此我不怀疑查询本身有问题。
但是，查询当前没有添加任何选项或参数。它很复杂，但只使用基本的 T-SQL 命令。由于安全问题，我无法将其发布在这里。
这是 C# 中的消息。连接字符串中的超时设置为零。
... ;Connect Timeout=0;
System.Data.SqlClient.SqlException（0x80131904）：执行超时已过期。操作完成之前超时时间已过，或者服务器没有响应。
如果我首先在 SSMS 中运行查询，我只能让 C# 程序运行。有时，如果我多次运行 C# 程序，它就会起作用。我们在其他应用程序中也看到了类似的超时。数据库大小为 433000 MB。在执行此基本查询后，C# 程序确实使用线程来执行子查询。
仅当数据库刚刚恢复或恢复数据库快照时才会发生这种情况。如果服务器/数据库重新启动等也会发生同样的情况
这听起来像是空缓存（和缓慢的驱动器）的问题。 SQL Server 总是希望在可能的情况下从 RAM 缓存加载数据，而不是从磁盘加载数据，但它不会预先将数据加载到 RAM 中进行缓存。相反，它会在使用数据时保留数据，因此以后的访问会更加高效。
因此，当您重新启动数据库时，随着缓存的预热，一开始速度会稍微慢一些，这是“正常”的。值得庆幸的是，这在任何精心设计的系统中都是“罕见的事件”。 我见过一些环境，他们会构建一个存储过程来循环每个表并对数据进行选择查询。它们在启动时运行它，因此 SQL Server 有理由在启动后立即填充缓存。 这可以适用于某些工作负载，或者如果您确实有足够的 RAM 来容纳
所有您的数据和索引，但更常见的是，此策略无法以正确的方式包含索引，并且会用实际上不会的数据污染缓存。被需要。
就您而言，听起来从某些表加载数据的有针对性的方法可能很有用。