sum(virtual_memory_reserved_kb) as [VM Reserved], --从buffer pool中保留的大小
sum(virtual_memory_committed_kb) as [VM Committed], --从buffer pool中提交的大小
--是Buffer Pool里的Stolen Memory的大小.在Buffer Pool中通过Stolen分配的,也就是直接Commit分配的内存量. sum(single_pages_kb) as [SinlgePage Allocator],
--分配的多页内存量(KB)，是使用内存节点的多页分配器分配的内存量。此内存在buffer pool外分配，是SQL Server自己的代码使用的MemToLeave大小。 sum(multi_pages_kb) as [MultiPage Allocator], --内存Clerk使用地址窗口化扩展插件(AWE)分配的内存量。当启用AWE时,只有缓冲池Clerk(MEMORYCLERK_SQLBUFFERPOOL)使用此机制，不可为空值。 --可以由buffer pool使用的内存量 sum(awe_allocated_kb) as [AWE Allocated],
sum(shared_memory_reserved_kb) as [SM Reserved], --内存Clerk保留的共享内存量,保留给共享内存和文件映射使用.
sum(shared_memory_committed_kb) as [SM Committed] --内存Clerk提交的共享内存量,和上面的字段一起可以追踪Shared Memory的大小.
from sys.dm_os_memory_clerks group by type order by type 4.接下来，是查询为什么变慢的问题。 向上面说的，可能是由于表经常进行插入，删除，修改，导致了存储碎片，这样会导致查询同样的数据，需要更多的IO，也需要更多的内存，那么效率自然下降，同时内存的效率下降，间接导致需要吃更多的内存，这个可以通过重建表和索引，来完成。 还有，就是随着数据的变化，表的统计信息不够准确，导致查询优化器不能够生成足够优化的执行计划， 那么查询自然会慢，这个主要是通过update statistics 表 ,来更新统计信息就可以。
2、先不考虑优化，可以使用性能监视器来查看是否真的有内存压力。这个你可以到网上找具体的计数器和阈值
#2.监控一下，看是哪些语句执行比较慢；看一下慢的原因，是为什么。才能下结论。
#3.一般来说，在既定的硬件条件下，优化索引是首选
1、过多的增删改操作，导致碎片增多。
2、库越来越大，索引效率降低，或者以前小表的时候即使没有索引都没所谓，现在很大了就显示出重要性。
3、有新的程序部署，影响了既有性能。
4、数据的增长没有计划性，比如短期内操作数量巨大的数据。
5、没有定期维护，到了一定时间段，就从量变到质变。
结论：
1、用性能监视器看看CPU，磁盘、内存等资源，参考网上的“建议”，初步评估和定位问题再哪里。
2、借助sqlserver自带功能，如profiler、dmv、DTA等来找到比较大开销的语句。进行优化。
3、做好定期维护，如索引维护、磁盘空间维护等。
2。是否有IO问题
3。内存是否有瓶颈
。
若有预算，欢迎联系ME
3.为了能了解是否真的有问题，首先，你得知道，这些内存都是花在哪儿了。 一般的内存，主要是由数据库页、sql执行计划、网络包等，如果数据大部分都是缓存的数据，那应该问题不大。但如果大部分都由sql执行计划，那就有问题了，可能是由于没有使用绑定变量，导致大量的重复语句，都缓存在内存中。
select
type,
sum(virtual_memory_reserved_kb) as [VM Reserved], --从buffer pool中保留的大小
sum(virtual_memory_committed_kb) as [VM Committed], --从buffer pool中提交的大小
--是Buffer Pool里的Stolen Memory的大小.在Buffer Pool中通过Stolen分配的,也就是直接Commit分配的内存量.
sum(single_pages_kb) as [SinlgePage Allocator],
--分配的多页内存量(KB)，是使用内存节点的多页分配器分配的内存量。此内存在buffer pool外分配，是SQL Server自己的代码使用的MemToLeave大小。
sum(multi_pages_kb) as [MultiPage Allocator], --内存Clerk使用地址窗口化扩展插件(AWE)分配的内存量。当启用AWE时,只有缓冲池Clerk(MEMORYCLERK_SQLBUFFERPOOL)使用此机制，不可为空值。
--可以由buffer pool使用的内存量
sum(awe_allocated_kb) as [AWE Allocated],
sum(shared_memory_reserved_kb) as [SM Reserved], --内存Clerk保留的共享内存量,保留给共享内存和文件映射使用.
sum(shared_memory_committed_kb) as [SM Committed] --内存Clerk提交的共享内存量,和上面的字段一起可以追踪Shared Memory的大小.
from sys.dm_os_memory_clerks
group by type
order by type
4.接下来，是查询为什么变慢的问题。
向上面说的，可能是由于表经常进行插入，删除，修改，导致了存储碎片，这样会导致查询同样的数据，需要更多的IO，也需要更多的内存，那么效率自然下降，同时内存的效率下降，间接导致需要吃更多的内存，这个可以通过重建表和索引，来完成。 还有，就是随着数据的变化，表的统计信息不够准确，导致查询优化器不能够生成足够优化的执行计划，
那么查询自然会慢，这个主要是通过update statistics 表 ,来更新统计信息就可以。
还有最关键的是，你的查询是否通过索引来访问数据，因为索引的效率更高，否则，用表扫描的话，效率非常差。