我正在使用SQL Server 2008 Enterprise。 我将向SQL Server发出大量的查询。 而且我认为SQL Server本身会在内部使用一些优化，比如将数据预提取到SQL Server内部数据caching中，或者在从物理页面文件加载之前从caching中访问频繁请求的数据以提高性能。
任何解决scheme，看看SQL Server内部caching命中率？ 或调整caching，使查询性能更好的任何最佳做法？
在此先感谢乔治
看看BOL： SQL Server，缓冲区pipe理器对象 。
你应该首先看两个领域是：
过程caching是SQL存储查询计划的内存区域。
缓冲区caching是存储数据页面的内存区域。
相关的性能计数器：
OLTP应用程序的主要SQL Server 2005性能问题包含以下内容：
CPU瓶颈如果…
信号等待总等待的25％。 有关信号等待和总等待，请参阅sys.dm_os_wait_stats。 信号等待测量在等待CPU的可运行队列中花费的时间。 高信号等待表示CPU瓶颈。
计划重复使用<90％。 查询计划用于执行查询。 对于OLTP工作负载来说，计划重用是可取的，因为重新创build相同的计划（对于类似或相同的事务）是浪费CPU资源。 比较SQL Server的SQL统计：批量请求/秒到SQL编译/秒。 计算计划重用如下：计划重用=（批量请求 – SQL编译）/批量请求。 计划重用规则的特殊例外：零成本计划不会在SQL 2005 SP2中被高速caching（不重用）。 使用零成本计划的应用程序将有较低的计划重用，但这不是一个性能问题。
并行等待typescxpacket>等待总数的10％。 为了执行速度，并行性牺牲CPU资源。 考虑到OLTP的高容量，并行查询通常会降低OLTP的吞吐量，应该避免。 请参阅sys.dm_os_wait_stats获取等待统计信息。
内存瓶颈，如果…
平均页面预期寿命一直较低。 请参阅Perfmon对象SQL Server缓冲区pipe理器中的平均页面预期寿命计数器（它表示页面在caching中的平均秒数）。 对于OLTP，平均页面预期寿命300是5分钟。 less一点可能表示内存压力，缺less索引或caching刷新。
页面预期寿命突然大幅下降。 OLTP应用程序（例如，小型事务）应该具有稳定（或缓慢增长）的页面预期寿命。 请参阅Perfmon对象SQL Server缓冲区pipe理器。
等待内存授予。 请参阅Perfmon对象SQL Server内存pipe理器中的计数器内存授予待定。 小的OLTP事务不应该需要大的内存授权。
突然下降或一致的低SQL Cache命中率。 OLTP应用程序（例如小事务）应该具有高caching命中率。 由于OLTP事务很小，所以不应该有（1）SQL Cache命中率大幅度下降，或者（2）caching命中率一直低于90％。 丢弃或低caching命中可能表示内存压力或缺less索引。