在IIS Web应用程序后面的SQL Server 2014中有一个20GB的数据库 - 数据库被全天候查询，因此它永远不会处于非活动状态，并且自动关闭已关闭，但是有一个手动触发的“每日工作队列”存储过程，该过程在一段时间内运行不一致第一次执行。
当它在早上第一次使用时它会慢慢运行 - 如果你等待，再次执行它会立即回复。同时服务器上的最小其他负载，页面预期寿命是健康的，并且应该具有支持此查询的必要索引 - 或者至少不建议使用其他索引。
一直试图将此作为查询优化问题处理并无处可去，因此开始探索其他想法。
从备份恢复数据库到本地开发服务器 - 第一次执行很慢，第二次执行很快，看到通过sys.dm_os_buffer_descriptors加载的大（500mb +）索引 - 如果我运行DBCC DROPCLEANBUFFERS来模拟从缓冲区卸载的所有内容，下一次执行会很慢，可以观察缓存的索引，这会使它快速执行。
似乎符合我们正在经历的模式，并且假设MSSQL可能会删除未使用超过10小时的数据似乎并不合理。
我错过了一些更明显的东西吗？假设我走在正确的道路上，不能成为第一个遇到这个问题的人，所以必须是一个优雅的解决方案...
答案 0 :(得分：0)
如果你的＆＃34;日常工作队列＆＃34;改变数据。然后索引需要在缓存中重建并重新加载。与开始一辆旧车相同，你需要稍等一下。
我所做的是计划那些＆＃34;工作＆＃34;在晚上并编写一些基本查询，以便在缓存中加载索引。
在第一次运行查询时检查硬件（磁盘，内存），db必须从磁盘中获取数据（慢）并将其存储在内存中（快速但小巧）。