辽宁
内存占用超80%，频繁重启成常态，SQL Server的真相与解决之道？
SQL Server 这东西确实好用，速度快，功能多，但就是有个毛病让人头疼——它总爱把内存吃光。好多公司的DBA或者开发人员，最后都懒得管了，直接写个定时任务，每天半夜重启一次SQL Server服务，眼不见心不烦。可这真的是解决之道吗？其实不是，这只是在掩耳盗铃。
为什么SQL Server这么爱占内存呢？这得从它的设计说起。SQL Server 的默认行为就是尽可能多地占用内存，它会把数据页、执行计划、连接池这些东西都缓存起来，这样查询就能快一点。微软官方文档也说了，只要系统不出现内存短缺，SQL Server 就会一直占着，直到占满为止。
举个例子，你服务器有64GB内存，SQL Server 可能吃掉80%到90%，剩下给操作系统和其他应用。但如果服务器只有32GB，它反而会主动释放一些，因为系统已经紧张了。所以，内存占用高不是Bug，是它故意的。
很多人碰到这种情况，第一个想到的就是重启服务。确实，一重启内存就全释放了，操作也简单。但带来的问题也很大：业务中断，用户掉线，程序报错。重启之后缓存全没了，查询变慢，这叫冷启动。长期靠重启，只能说明你的内存配置不合理，等于用运维体力换偷懒。
还有的人会执行DBCC FREEPROCCACHE那些命令，想清除缓存。但这么做其实不会立刻把内存还给操作系统，只是阻止SQL Server继续申请新内存。而且频繁清理会导致计划重新编译，CPU开销变大，性能反而下降。
更离谱的是，有人先手动把最大服务器内存调成很小值，比如200MB，让SQL Server释放内存，再调回正常值。这要是设置得过低，SQL Server 可能直接挂掉或者崩溃，风险太大。
其实，真正科学的方法很简单，就是给SQL Server 设置一个上限。叫“最大服务器内存”，也就是Max Server Memory。你可以通过SSMS或者用sp_configure命令来设置。比如，服务器一共64GB内存，给操作系统和其他应用留20%左右，大概12GB，剩下的52GB给SQL Server。这样它就不会无限制地吃内存了。
设置的时候注意，64位系统不用管AWE；32位系统需要启用AWE并锁定内存页。设置完执行RECONFIGURE，动态生效，不需要重启。这个方法从根本上限制了SQL Server的胃口，而且不会影响业务。
如果你想更灵活一点，还可以用脚本动态调整。比如在业务低谷的时候，先把最大服务器内存降下来，过10秒再调回去，这样SQL Server 就会被迫释放一部分缓存。这种操作叫“软释放”。不过要注意，降低的数值不能太低，最好不低于当前实际占用内存的80%，否则容易出问题。
另外，还可以定期清理缓存。比如写个SQL Server Agent作业，每15分钟跑一次，检查当前内存占用和目标内存的比例。如果占比超过90%并且业务空闲，就执行DBCC FREEPROCCACHE之类的命令。但这也只能释放部分缓存，不能完全替代设置最大内存。
除了这些，优化查询也很重要。设置合理的锁超时时间，避免长时间锁等待占用资源。优化慢查询，减少排序和哈希操作需要的内存授予。用sys.dm_os_memory_clerks这些动态视图，看看具体哪个模块吃内存最多，然后针对性地处理。
在生产环境里，最好的做法是提前规划。根据业务负载和服务器内存，一开始就设置好最大服务器内存，推荐总内存的70%到80%。然后持续监控，用性能计数器查看内存使用情况，设置告警阈值。不同业务场景需求也不一样，OLTP系统重数据缓存，OLAP系统重查询内存，要分别调整。
SQL Server 2012及以上版本的内存管理更智能，但核心行为一样。高版本比如2016以上，还可以启用内存中OLTP，那需要额外预留内存。Linux环境下也一样，用sp_configure设置，但要注意容器环境下的资源限制，比如Docker的--memory参数。
总之，别再天天写定时重启服务了。那只是用一种傻办法掩盖另一种傻。真正解决问题，是理解SQL Server的设计，合理配置最大内存，再辅以动态清理脚本，这样就能和平共处。DBA应该把精力放在性能优化和架构设计上，而不是每天应付内存问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
