SQL Serve里你总要去改变的3个配置选项

你用安装向导安装了全新的SQL Server,最后你点击了完成按钮。哇噢~~~现在我们可以把我们的服务器进入生产了!抱歉,那并不是真的,因为你的全新SQL Server默认配置是错误的。

是的,你没看错:SQL Server的默认安装在很多方面的配置是错误的。在今天的文章里,我想给你展示下,为了更快的性能,在SQL Server安装完成后3个你需要立即修改的配置选项。我们开始吧!

最大服务器内存(Max Server Memory)

免责声明:如果这些天你在32位系统上运行你的SQL Server,请扔掉你的硬件,买个64位的系统,安装64位的SQL Server,然后从这里继续读。

现在在你面前你应该i有个64位的SQL Server。64位意味着你可以理论上访问2^64的内存大小——那是16艾字节(10亿GB)!因为这些巨量的内存,计算机供应商当前限制64位系统的地址总线“只有”48位——完全64位没有真正意义。用48位的地址空间,你可以访问256TB的内存——那还是大量的空间。

你可以使用最大服务器内存配置选项来配置SQL Server可以消耗的内存大小。下图显示的是在64位系统上SQL Server默认安装后的配置选项。

从刚才的图片你可以看到,SQL Server默认配置是可以消耗上至2147483647MB的内存——那是2千兆!嗯,用48位的地址总线我们只能物理访问256TB的内存,现在SQL Server可以消耗上至2千兆的内存?这里有什么东西不对……最大服务器内存设置比32位最大整形值还大——2147483647。没别的。因此SQL Server可以消耗比物理地址更多的内存?这是一个很不好的默认配置。SQL Server默认可以吃光你整个物理内存!

你总应该改变这个配置选项,这样的话你可以给系统一些内存,让它可以活着喘气。一般来说(在服务器上没有其它程序/进程)你应该系统至少10%的物理内存。这就是说你需要调低最大服务器内存设置。有64GB的物理内存我会配置最大服务器内存为56GB,这样的话系统可以用剩下的8G来消耗和工作。

并行开销阀值(Cost Threshold for Parallelism)

下一个你需要修改的配置选项是SQL Server处理并行开销的阀值。并行意味着SQL Server能透过多个工作线程运行执行计划里的运算符。并行的目的是提高你查询的吞吐量。SQL Server里第1个影响并行的配置选项是所谓的并行开销阀值

这里你配置的数字定义查询成本,查询优化器用它来找更便宜的并行执行计划。如果找到的并行计划更便宜,这个计划会被执行,不然串行计划会被执行。从刚才的图你可以看到,SQL Server默认配置使用5的成本阀值。当你的串行计划查询成本大于5,然后查询优化器再次运行查询优化来找更便宜并行执行计划的可能。

遗憾的是,5的成本值当下来说是个很小的数字。因此SQL Server太快尝试并行你的执行计划。当你处理更大的查询并行才有意义——例如报表或数据仓库情形。在纯OLTP情形下,并行计划象征着糟糕的索引设计,因为当你有缺失索引时,SQL Server需要扫描你的整个聚集索引(在与过滤(Filter)和剩余谓语(residual predicate)组合里),因此你的查询成本越来越大,它们穿过成本阀值,最后查询优化器给你并行计划。当人们看到并行计划时,总会担心!但问题根源是缺失非聚集索引。

对于并行的成本阀值,我总推荐至少20,甚至50。那样的话,你确保SQL Server只为你对更大的查询进行并行。即使在你面前有个并行计划,你也应该考虑下可否通过增加一个支持的非聚集索引来是这个查询成本更低。另外,CXPACKET并不象征着在你的系统里你有并行问题!

最大并行度(Max Degree of Parallelism (MAXDOP))

当在SQL Server里一个执行计划进入并行,最大并行度定义了执行计划里每个并行运算符可用工作线程。下图显示了这个选项的默认配置。

如你所见,SQL Server使用默认值0。这个值意味着SQL Server尝试并行化你的执行计划穿过分配给SQL Server的所有CPU内核(默认情况所有内核都分配给SQL Server!)。你应该能看出这样的设置没有意义,尤其当你有大量CPU内核的系统。并行化本身带来负担,一旦你使用越多的工作线程,这个负担越大。

一个建议是设置最大并行度为在一个NUMA结点里拥有的内核数。因此在查询执行时,SQL Server会尝试在一个NUMA结点里保持并行计划,这也会提高性能。

有时你也会看到建议去设置最大并行度为1。这个是不好的建议,因为这个使你的“整个”SQL Server 单线程!即使维护操作(例如索引重建)已单线程执行,这会严重伤及性能!当然也有一些“获奖”产品指示你使用1的最大并行度(MAXOP)……

将承载 SharePoint 数据库的 SQL Server 实例的最大并行度 (MAXDOP) 设置为 1 以确保单个 SQL Server 过程能够为每个请求提供服务。

小结

在你安装完SQL Server后,DBA的真正工作才开始:你需要配置你的SQL Server安装到你的硬件配置。在这篇文章里你已看到,SQL Server的默认配置是明显错误的。因此在安装后立即修改一些配置选项非常重要。我已经见过生产环境里SQL Server使用我这里提到的默认选项,因为它们“稍后“会被配置,“稍后”就从未发生了……

因此今天请帮自己一个忙,为最大性能和吞吐量配置你的SQL Server!

感谢关注!

时间: 2024-08-04 16:10:27

SQL Serve里你总要去改变的3个配置选项的相关文章

SQL Server安装完成后3个需要立即修改的配置选项(转载)

你用安装向导安装了全新的SQL Server,最后你点击了完成按钮.哇噢~~~现在我们可以把我们的服务器进入生产了!抱歉,那并不是真的,因为你的全新SQL Server默认配置是错误的. 是的,你没看错:SQL Server的默认安装在很多方面的配置是错误的.在今天的文章里,我想给你展示下,为了更快的性能,在SQL Server安装完成后3个你需要立即修改的配置选项.我们开始吧! 最大服务器内存(Max Server Memory) 免责声明:如果这些天你在32位系统上运行你的SQL Serve

SQL Server里等待统计(Wait Statistics)介绍

在今天的文章里我想详细谈下SQL Server里的统计等待(Wait Statistics),还有她们如何帮助你立即为什么你的SQL Server当前很慢.一提到性能调优,对我来说统计等待是SQL Server了最重要的概念. 查询为什么等待 在SQL Server里每次你执行1个查询,查询总需要等待.什么?查询总需要等待?是的,你没有看错:但给你执行1个查询时,查询总需要等待.为什么查询需要等待的原因是SQL Server通过所谓的等待统计(Wait Statistics)来跟踪的.在我进入等

SQL Server里的自旋锁介绍

在上一篇文章里我讨论了SQL Server里的闩锁.在文章的最后我给你简单介绍了下自旋锁(Spinlock).基于那个基础,今天我会继续讨论SQL Server中的自旋锁,还有给你展示下如何对它们进行故障排除. 为什么我们需要自旋锁? 在上篇文章我已经指出,用闩锁同步多个线程间数据结构访问,在每个共享数据结构前都放置一个闩锁没有意义的.闩锁与此紧密关联:当你不能获得闩锁(因为其他人已经有一个不兼容的闩锁拿到),查询就会强制等待,并进入挂起(SUSPENDED)状态.查询在挂起状态等待直到可以拿到

如何用O2O去改变充满谎言、疑虑和愤怒的维修行业

为什么千亿级的维修服务市场出不了行业巨头? 据相关统计,我国的整个维修服务市场规模可达每年数千亿元之巨(其中仅家电维修就可达近千亿规模,更遑论手机.数码.家具等维修).同样是千亿级规模的服务行业,快递业已经出现顺丰和四通一达这样百亿级的行业巨头,零售行业更是早已有苏宁国美这样的超级巨头存在.做为同等体量的维修市场,为什么迟迟不见巨头的身影而长年保持着小散乱差的"口碑"呢? 以上海市场为例,在做"报修一站通"项目过程中,我们接触了近6千家各种类型的维修网点,其中超过八

SQL Server里如何随机记录集

今天的文章,我想给你简单介绍下SQL Server里如何随机记录集. 1 SELECT * FROM Person.Person 2 ORDER BY NEWID() 3 GO 这会引入新的UNIQUEIDENTIFIER数据类型列,SQL Server会在那列上进行物理排序操作. 但是在记录集里列本身没有返回,因为ORDER BY子句在查询SELECT部分逻辑后发生,因此也不会改变记录集. 在SQL Server里,简单但很强大的方法用来随机化你的记录集. 感谢关注!

SQL Server里ORDER BY的歧义性

在今天的文章里,我想谈下SQL Server里非常有争议和复杂的话题:ORDER BY子句的歧义性. 视图与ORDER BY 我们用一个非常简单的SELECT语句开始. 1 -- A very simple SELECT statement 2 SELECT * FROM Person.Person 3 ORDER BY LastName 4 GO 从刚才列出的代码你可以看到,我们只想从Person.Person表以LastName列排序返回记录.因为我们想能尽可能简单的重用那个SQL语句,最后

SQL Server里的闩锁介绍

在今天的文章里我想谈下SQL Server使用的更高级的,轻量级的同步对象:闩锁(Latch).闩锁是SQL Server存储引擎使用轻量级同步对象,用来保护多线程访问内存内结构.文章的第1部分我会介绍SQL Server里为什么需要闩锁,在第2部分我会给你介绍各个闩锁类型,还有你如何能对它们进行故障排除. 为什么我们需要闩锁? 闩锁首次在SQL Server 7.0里引入,同时微软首次引入了行级别锁(row-level locking).对于行级别锁引入闩锁的概念是非常重要的,不然的话在内存中

SQL Server里PIVOT运算符的”红颜祸水“

在今天的文章里我想讨论下SQL Server里一个特别的T-SQL语言结构——自SQL Server 2005引入的PIVOT运算符.我经常引用这个与语言结构是SQL Server里最危险的一个——很快你就会知道为什么.在我们进入特定问题和陷阱前,首先我想给你下使用SQL Server里的PIVOT能实现什么的一个基本概述. 概述 SQL Server里PIVOT运算符背后的基本思想是在T-SQL查询期间,你可以旋转行为列.运算符本身是SQL Server 2005后引入的,主要用在基于建立在实

oracle 与sql serve 获取随机行数的数据

Oracle 随机获取N条数据    当我们获取数据时,可能会有这样的需求,即每次从表中获取数据时,是随机获取一定的记录,而不是每次都获取一样的数据,这时我们可以采取Oracle内部一些函数,来达到这样的目的1) select * from (select * from tablename order by sys_guid()) where rownum < N; 2) select * from (select * from tablename order by dbms_random.va