我们每周和每月运行一次维护窗口。我们的一些维护窗口是在线的，我们最不想要的就是我们的脚本阻止来自我们应用程序的实时查询。
有没有办法设置查询的优先级，使其不会导致其他查询阻塞超过 X 秒？
例子：
我知道死锁有类似的功能（将死锁受害者设置为低）。
谢谢！
我们有峰值，其中延迟（根据数据文件所在驱动器上的 [Physical Disk\Avg Disk Sec read] 测量）高达 0.2 秒。
我立即开始怀疑 SAN，而 DBA 怀疑这与我们目前只有一个 5 TB 的 MDF 文件有关。
非常大的 MDF 文件是否会对延迟产生负面影响？如果是这样，合适的尺寸是多少？
我没有看到很多关于这个主题的内容。
谢谢！-泽维尔
设想
假设我有一个带有 4 个套接字的 SQL Server，每个套接字有 1 个 NUMA 节点。每个插槽有 4 个物理内核。总共有 512 GB 的内存，因此每个 NUMA 节点有 128 GB 的 RAM。
一个密钥表被加载到第一个 NUMA 节点中。
问题
假设我们从该表中读取了大量流量。如果拥有 NUMA 节点的套接字的所有物理核心都具有 100% 的 CPU 使用率，这是否会对来自其他套接字的非本地 NUMA 访问的成本产生负面影响？或者另一方面，非本地 NUMA 访问的成本与该套接字的繁忙程度无关？
我希望我的问题是有道理的。如果没有，请告诉我，我会尽力澄清。
背景
上周我们的生产服务器出现数据库问题，我们处理的一些业务似乎比其他业务受到的影响更大。我们有一些逻辑读取时间超过 1 分钟的查询。我们查看了大约 60% 的整体 CPU 利用率。我们没有查看特定于套接字的 CPU 指标。I/O 指标是平均水平。