我们有一台运行SQL Server 2005 64位的强大的Windows 2008 x64服务器（4 x 4核心CPU，32GB RAM）。 我们有一个小的（6GB）但非常重要的数据库，访问起来有点慢，直到页面被caching到内存中（这个用法是非常随机的I / O，所以给定的页面在内存中的可能性非常低，最终用户抱怨最初的缓慢）。 磁盘速度够快（本地15K SAS），但我猜应用程序有点笨拙（这是一个COTS解决scheme），所以我想知道是否有一种方法来强制在SQL Server 2005中的内存中的数据库（2008年不支持由供应商，所以我们不应该升级到这一点），以帮助避免初始caching填充布鲁斯？
我目前的方法是，我从脚本中的每个表运行一个SELECT *来获取内存中的数据页，但是一些对象（索引，全文search等）没有被这个方法caching（并修改脚本来查询索引和编写适当的WHERE子句来caching是熬海复杂的）。
不，不幸的是，没有办法强制数据库进入caching。 你的蛮力方法可能是最直接的。 你可以通过使用非常低的阈值设置来使用索引碎片整理脚本，比如说如果索引是1％分片，就重build索引，就像这样：
http://sqlserverpedia.com/wiki/Index_Maintenance
这将需要更长的时间，并涉及到更多的写入磁盘，但它会有碎片整理您的索引和更新统计数据的副作用，无论如何这是一个好主意。
好吧 – 我不能评论布伦特的答案（但是，因为我没有足够的代表） – 但是如果你要去碎片整理路线，不一定重build索引 – 因为这将build立新的索引，如果没有足够的可用空间，可能会增长数据库，并且保证您的下一个日志备份至less是索引的大小，并且您的日志也可能有大量的日志logging（取决于恢复模式）。 如果你打算做碎片整理的路线，做一个ALTER INDEX … REORGANIZE，它不需要任何可用空间（好，一个8K页），但是会把叶级读入内存，并且只对碎片进行操作页面。 在一些查询之后，非叶级别应该快速进入，并且（取决于扇出）应该是比叶级更less的数据。
为什么首先从caching刷新数据库对象？ 您是否重新启动SQL服务或closures/联机数据库？ 还是被从其他数据库caching推出？
问候，
SCM。
如果数据库很小，可以考虑把它放在SSD上？
我已经有一些情况下更新统计与关键表上的FULLSCAN已经强制数据caching，并使我后来的DML周围的表快很多。 这不是过时统计的结果，因为它没有改变执行计划。
为什么不安装只有该数据库的第二个 SQL Server 实例 ，并将该实例的最小内存设置为6GB？
这将保证你的其他数据库永远不会从你的“小但非常重要的”数据库中窃取内存。
这也意味着你可以把另一个实例脱机，你的小数据库将保留在内存中。
我会使用分析器来检查你的SQL。 比较“逻辑”读取和“物理”读取。 SQL服务器是聪明的，将使用它所需要的RAM来获得最高效的结果。
还要检查你的自动恒星是否是最新的。
没有更多的关于查询types和分贝表大小的想法，这听起来有点奇怪。