Page Reads/sec

 Lazy writes/sec

Page life expectancy 

问：我系统内存本来就不够为什么还要设置使用上限？我这服务器就给数据库用还用设置？

答：数据库是运行在windows 上的应用，他和notepad对于操作系统来说本质上没区别，那么这就好比君（操作系统）与 臣（数据库）的关系。

而SQL SERVER是一个很喜欢内存的应用，所以很可能吃掉大量内存导致windows系统没有足够内存使用，，那么这时候君臣关系就体现的淋漓尽致了，君(windows) 要臣（SQL SERVER）死（释放内存）臣不得不死呀...这个释放在一定程度上可不是单单让windows够用了，很可能导致SQL内存陡降，以致SQL 短时间假死（操作无响应）。所以为了你数据库的稳定性，这个最大上限一定要设置。

内存设置推荐：

       一般我比较推荐如果内存较小操作系统预留3G-4G ，如果内存大256或512以上在数据库内存无压力时预留5%给操作系统，剩下给SQL SERVER ，如果服务器还有其他应用还要在SQL 中减掉应用所占的内存。

　　如果内存比较小且数据库内存压力大，则可以通过前面讲述的Available MBytes 的判断结果适量给系统预留内存。

注意：最大内存的设置单位为 MB。

语句的优化，让语句消耗内存更少！

　　　　语句优化系列请关注后续文章，这里只针对降低内存

　　　　降低内存对语句优化主要集中在几个方面：

1. 1. 1. 是否缺失索引？ 
      2. 消耗内存的操作是否可以消除（如排序）
      3. 降低语句复杂性，让优化器能选用最佳计划

　　　　语句消耗内存主要体现在大量的读取，或者有排序等操作。

　　　　所谓的读，简单理解就是在语句执行时所需要用到的数据页数，需要的越多就需要越大的内存来缓存这些数据页。如果需要的页不在内存中还需要从磁盘读取 （磁盘读取就是为什么Page Reads/sec 会高）

　　　　简单的一个加索引降低逻辑读的例子~

　　　　语句使用了一个整个表扫描的计划，执行了 19秒，逻辑读取143800次，预读137236 （磁盘上读取），消耗了40KB 的内存 ，并且明确提示出缺少索引！

　　　　那么我们加上提示缺少的索引，再次执行

　　　　加上索引的语句执行不到1秒 逻辑读降低到13次，内存消耗已经可以忽略不计。这就是索引对语句的重要性！单条语句如此，你的系统中到底有多少这样的语句呢？

　　　　再来看一个写法修改的例子 ：

　　　　只是简单的改了下语句的写法时间有7秒变成1秒，内存消耗从300+MB 变成 1MB

　　　　这两个例子，告诉我们也许系统中简简单单做一些调整，内存的压力就会明显降低或者变得非常充足，所以在你下了一个需要购买内存的决定前，是否针对系统的语句进行过调优？

步骤4.内存问题分析与解决（特殊排查步骤）

            如果你是系统维护人员，看到类似这样的内存数据指标，如果你还不能有一些思路，请你好好熟悉下你的系统。

　　　　这张图很清晰地反映出系统每隔几小时会有一次的内存压力，那么别忙着去找对应时间点的语句，我们最少要好好想一下，系统中有什么操作定时执行？SQL JOB？计划任务？前台定时处理？等等等

　　　　这个规律的定时处理是否有异常？是否最近有什么改动？执行的结果是不是和你想的一样？

　　　　也许问题就这么清晰的定位了......

 -----------------------------------------------------------------------------------------------------

　　总结：内存对于数据库来说是最为重要的依赖之一，内存的问题诊断和优化对系统至关重要。

　　　　　优化语句可以让你的系统内存压力明显降低。

　　　　　语句优化所带来的效果，在很大程度上会比添加硬件更有效！

　　　　　作为一个技术人员对于系统问题的定位、分析、调优是最重要的。