sqlserver事务性能 sqlserver 事务

sqlserver2008与2016的性能差异

SQL Server 2008 与 SQL Server 2016 的性能差异较大，SQL Server 2016 在性能方面有了很大的改善。

首先，SQL Server 2016 通过动态管理视图（DMV）和活动报表（AR）来提高性能，提供自动智能优化、自动智能引擎级别缓存、查询优化处理程序和自动智能查询识别等功能，帮助开发者更快地识别不均衡的查询和数据库，从而改善性能。

其次，SQL Server 2016 也改进了许多性能，如改进的 Buffer Pool Cache 和 Column Store Index，以及支持部分和完整索引维护功能，这些新功能都有助于改善查询的执行性能和响应时间。

此外，SQL Server 2016 也支持新的 In-Memory OLTP，它可以帮助提高大量事务型处理（OLTP）系统的性能，改善数据存储和读取速度。

总之，SQL Server 2016 比 SQL Server 2008 在性能方面有很大的改善，可以大大提升系统的效率和性能。

相关问答

Q1: SQLServer和Oracle数据库分析(oraclesql性能分析)

分析原则：

1、具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

2、查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。分段排除法很有效。

分析的信息来源：1、根据场景运行过程中的错误提示信息；

2、根据测试结果收集到的监控指标数据。

一、错误提示分析

分析实例：

1、Error:“10.10.10.30:8080〃:[10060]Connection

Error::Server“10.10.10.30〃

分析：

A、应用服务死掉（小用户时：程序上的问题。程序上处理数据库的问题）

B、应用服务没有死（应用服务参数设置问题）

例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AeptBacklog属性值设得过低。如果连接时收到消息，说明应提高该值，每次增加25%

C、数据库的连接（1、在应用服务的性能参数可能太小了；2、数据库启动的最大连接数（跟硬件的内存有关）。）

分析：可能是以下原因造成

A、应用服务参数设置太大导致服务器的瓶颈；B、页面中图片太多；C、在程序处理表的时候检查字段太大多。

二．监控指标数据分析

1、最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么可行。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2、业务操作响应时间：

分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。细分事务并分析每个页面组件的性能。如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3、服务器资源监控指标：内存：

1、UNIX资源监控中指标内存页交换速率（Pagingrate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2、Windows资源监控中，如果Process计数器和ProcessWorkingSet计数器的值在长时间内持续升高，同时Memory计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆：很高的换页率()；进程进入不活动状态；交换区所有磁盘的活动次数可高；可高的全局系统CPU利用率；内存不够出错()。

处理器：

1、UNIX资源监控（Windows操作系统同理）中指标CPU占用率（），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQLServer，可接受的最大上限是80-85%合理使用的范围在60%至70%。

2、Windows资源监控中，如果System大于2，而处理器利用率（）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆：很慢的响应时间()；CPU空闲时间为零()；过高的用户占用CPU时间()；过高的系统占用CPU时间()；长时间的有很长的运行进程队列()。

磁盘I/O：

1、UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Diskrate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

2、Windows资源监控中，如果DiskTime和Avg.DiskQueueLength的值很高，而PageReads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆：过高的磁盘利用率(highdiskutilization)；

太长的磁盘等待队列(largediskqueuelength)；

等待磁盘I/O的时间所占的百分率太高(largepercentageoftimewaitingfordiskI/O)；

太高的物理I/O速率：largephysicalI/Orate(notsufficientinitself)；

过低的缓存命中率(lowbuffercachehitratio(notsufficientinitself))；

太长的运行进程队列，但CPU却空闲(largerunqueuewithidleCPU)。

4、数据库服务器：

SQLServer数据库：

1、SQLServer资源监控中指标缓存点击率（CacheHitRatio），该值越高越好。如果持续低于80%，应考虑增加内存。

2、如果FullScans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。

3、NumberofDeadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

4、LockRequests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：

1、如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率：select(sum(pins-reloads))/sum(pins)fromv$librarycache；

select(sum(gets-getmisses))/sum(gets)fromv$rowcache；

自由内存：select*fromv$sgastatwherename=‘freememory’。

2、如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：selectname,valuefromv$sysstatwherenamein(‘dbblockgets’，‘consistentgets’‘physicalreads’)HitRatio=1-(physicalreads/(dbblockgetsconsistentgets))。

3、如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况：selectname，valuefromv$sysstatwherename=‘redologspacerequests’。

4、如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。

内存排序命中率：selectround((100*b.value)/decode((a.valueb.value)，0，1，(a.valueb.value)),2)fromv$sysstata，v$sysstatbwherea.name=’sorts(disk)’andb.name=’sorts(memory)’

注：上述SQLServer和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

Q2: SQL数据库中事务回滚会影响性能吗

首先性能肯定受影响，因为要反向回滚操作。

以sqlserver为例，如果是插入操作，回滚期间锁表，而且一般级别数据库消耗时间接近1:3。如果插入进行了1小时有可能要超过3小时多来完成回滚，此时不要强行关闭数据库或者杀死进程，也为无论如何为了保持acid特性也不会中止回滚只能等。

Q3: 如何识别SQL Server中的IO瓶颈

当数据页经常从缓冲池中移进移出的时候，I/O子系统就会成为SQLServer性能问题的关键因素之一。事务日志和tempdb同样也会产生重大

的I/O压力。因此，你必须确保你的I/O子系统能按照预期运行。否则你将会成为响应时间增长和频繁超时的受害者。在这篇文章中，将描述如何使用内置工具

识别I/O相关瓶颈，并提供一些磁盘配置的方法：

性能计数器（Performance Monitor）：

可以使用性能计数器来检查I/O子系统的负荷。下面的计数器可用于检查磁盘性能：

PhysicalDisk Object:Avg.DiskQueue Length：计算从物理磁盘中的平均

读和写的请求队列。过高的值代表磁盘操作处于等待状态。当这个值在SQLServer峰值时长期超过2，证明需要注意了。如果有多个硬盘，就需要把这些数

值除以2。比如，有4个硬盘，且队列为10，那么平均值就是10/4=2.5，虽然也证明需要关注，但不能使用10这个值。

Avg.Disk Sec/Read和Avg.Disk Sec/Write：显示从磁盘读或者写入磁盘的平均时间。10ms内是很好的表现，20以下还算能接受。高于此值证明存在问题。

Physical Disk:%Disk Time：在磁盘忙于读或者写请求的时候持续时间的比率。根据拇指定律，此值应该小于50%。

Disk Reads/Sec和Disk Writes/Sec计数器显示出在磁盘中读写操作的速率。这两个值应该小于磁盘能力的85%。当超过此值，磁盘的访问时间将以指数方式增长。

可以通过以下方式来计算逐渐增长的负载的能力。一种方法是使用SQLIO。你应该找到吞吐量比较稳定，但缓慢增长。

可以使用以下公式来计算RAID配置：

Raid 0: I/O per disk = (reads + writes) / number ofdisks

Raid 1: I/O per disk = [reads + (writes*2)] / 2

Raid 5: I/O per disk = [reads + (writes*4)] / number of disks

Raid 10: I/O per disk = [reads + (writes*2)] / number of disks

比如：对于RAID 1，如果得到下面的计数器：

Disk Reads/sec = 90

Disk Writes/sec =75

根据公式：[reads + (writes*2)] / 2 or [90 + (75*2)] / 2 = 120I/Os每个磁盘。

动态管理视图（DMVs）：

有很多游泳的DMVs可以用于检查I/O瓶颈：

当一个页面被用于读或者写访问且页面在缓冲池中不存在或不可用时，会引发一个I/O闩锁等待（I/O

latch），它会在PAGEIOLATCH_EX/PAGEIOLATCH_SH（具体根据请求类型而定）。这些等待表明一个I/O瓶颈。可以使用

sys.dm_os_wait_stats找到闩锁等待的信息。如果你保存了SQLServer正常运行下的waiting_task_counts和

wait_time_ms值，并且于此次的值做对比，可以识别出I/O问题：

select *

from sys.dm_os_wait_stats

where wait_type like 'PAGEIOLATCH%'

order by wait_type asc

挂起的I/O请求可以在下面查询中查到，并且用于识别那个磁盘负责的这个瓶颈：

select database_id,

file_id,

io_stall,

io_pending_ms_ticks,

scheduler_address

from sys.dm_io_virtual_file_stats(NULL, NULL) iovfs,

sys.dm_io_pending_io_requests as iopior

where iovfs.file_handle = iopior.io_handle

磁盘碎片（Disk Fragmentation）：

建议你检查磁盘碎片和配置用于SQLServer实例的磁盘。在NTFS文件系统中的碎片会产生严重的性能影响。磁盘需要经常整理碎片并且指定整理碎片计划。研究表明，一些情况下SAN在整理碎片后性能更差。因此，SAN必须根据实际情况对待。

NTFS上的索引碎片同样能引起高I/O好用。但是这和在SANs中的效果是不一样的。

磁盘配置/最佳实践：

常规情况，你应该把日志文件和数据文件分开存放以获得更好的性能。对于重负载的数据文件（包括tempdb）的I/O特性是随机读取。对于日志文件，是顺序访问的，除非事务需要回滚。

对于内置磁盘仅仅可以用于数据库日志文件，因为它们对顺序I/O有很好的性能，但是对随机I/O性能低下。

数据库的数据和日志文件应该放在对应专用的磁盘中。确保良好的性能。建议日志文件放在两个内置磁盘，并配置为RAID 1。数据文件驻留在仅用于给SQLServer访问的SAN系统中，并只被查询和报表控制。特殊访问应该被禁止。

写缓冲在可能的情况下应该被允许，并保证断电也能使用。

为了尽可能保证对于OLTP系统的I/O瓶颈影响最小化，不应该把OLAP和OLTP环境混合。并且保证你的代码优化及有合适的索引来避免不必要的I/O。

Q4: SQLServer与MySQL性能相差多大

SQL，在这里我理解成SQLServer。三者是目前市场占有率最高（依安装量而非收入）的关系数据库，而且很有代表性。排行第四的DB2（属IBM公司），与Oracle的定位和架构非常相似，就不赘述了。

如果要说明三者的区别，首先就要从历史入手。

Oracle：中文译作甲骨文，这是一家传奇的公司，有一个传奇的大老板LarryEllision。Ellision32岁还一事无成，读了三个大学，没得到一个学位文凭，换了十几家公司，老婆也离他而去。开始创业时只有1200美元，却使得Oracle公司连续12年销售额每年翻一番。

Oracle成立于1977年，早期的理论基础，反而来自于一篇IBM的论文《ARelationalModelofDataforLargeSharedDataBanks》【1】。作者CODD选取了关系代数的五种运算，并基于运算，架构了一种新型的数据存储模型。基于这种模型，Oracle成为了一个非常典型的关系数据库。因此也变的严谨、安全、高速、稳定，并且变的越来越庞大。

由于其诞生早、结构严谨、高可用、高性能等特点，使其在传统数据库应用中大杀四方，金融、通信、能源、运输、零售、制造等各个行业的大型公司基本都是用了Oracle，早些年的时候，世界500强几乎100%都是Oracle的用户。

MySQL：MySQL的最初的核心思想，主要是开源、简便易用。其开发可追溯至1985年，而第一个内部发行版本诞生，已经是1995年。到1998年，MySQL已经可以支持10中操作系统了，其中就包括win平台。但依然问题多多，如不支持事务操作、子查询、外键、存储过程和视图等功能。下图是一个截止至2006年的数据库市场占有率【2】：

图中可以看出，MySQL的爆发实际是在01、02年，尤其是02年发布的4.0Beta版，正式选定InnoDB作为默认引擎，对事务处理能力及数据缓存能力有了极大的提高。同年4.1版开始支持子查询，至此MySQL终于蜕变成一个成熟的关系型数据库系统。05年的5.0版本又添加了存储过程、服务端游标、触发器、查询优化以及分布式事务功能，但同年被Oracle抄了后路，InnoDB被Oracle收编。08年，MySQL被Sun收购，09年，Oracle收购了Sun和MySQL。

SQLServer：一提到SQLServer，大家一般都只想到MicrosoftSQLServer，而非SybaseSQLServer。SQLServer最初是由Microsoft,SybaseandAshton-Tate三家公司拦下的生意，是为IBM（又出现了）公司的OS/2操作系统开发的。随着OS/2项目的失败，大家也分道扬镳。Microsoft自然转向自己的win操作系统，作为windowsNT软件方案的一部分。而Sybase则专注于Linux/Unix方向的数据库开发。

MSSQLServer主要面向中小企业。其最大的优势就是在于集成了MS公司的各类产品及资源，提供了强大的可视化界面、高度集成的管理开发工具，在快速构建商业智能（BI）方面颇有建树。MSSQLServer是MS公司在软件集成方案中的重要一环，也为WIN系统在企业级应用中的普及做出了很大贡献。

典型应用场景

关于“大型数据库”，并没有严格的界定，有说以数据量为准，有说以恢复时间为准。如果综合数据库应用场景来说，大型数据库应用有以下特点：海量数据、高吞吐量；复杂逻辑、高计算量，以及高可用性。从这点上来说，Oracle，DB2就是比较典型的大型数据库，SybaseSQLServer也算是吧。下面分别说明之前三种数据库的应用场景。

Oracle。Oracle的应用，主要在传统行业的数据化业务中，比如：银行、金融这样的对可用性、健壮性、安全性、实时性要求极高的业务；零售、物流这样对海量数据存储分析要求很高的业务。此外，高新制造业如芯片厂也基本都离不开Oracle；电商也有很多使用者，如京东（正在投奔Oracle）、阿里巴巴（计划去Oracle化）。而且由于Oracle对复杂计算、统计分析的强大支持，在互联网数据分析、数据挖掘方面的应用也越来越多。一个典型场景是这样的：

某电信公司（非国内）下属某分公司的数据中心，有4台OracleSun的大型服务器用来安装Solaris操作系统和Oracle并提供计算服务，3台SunStorage磁盘阵列来提供Oracle数据存储，12台IBM小型机，一台OracleExadata服务器，一台500T的磁带机用来存储历史数据，San连接内网，使用Tuxedo中间件来保证扩展性和无损迁移。建立支持高并发的Oracle数据库，通过OLTP系统用来对海量数据实时处理、操作，建立高运算量的Oracle数据仓库，用OLAP系统用来分析营收数据及提供自动报表。总预算约750万美金。

MySQL。MySQL基本是生于互联网，长于互联网。其应用实例也大都集中于互联网方向，MySQL的高并发存取能力并不比大型数据库差，同时价格便宜，安装使用简便快捷，深受广大互联网公司的喜爱。并且由于MySQL的开源特性，针对一些对数据库有特别要求的应用，可以通过修改代码来实现定向优化，例如SNS、LBS等互联网业务。一个典型的应用场景是：

某互联网公司，成立之初，仅有PC数台，通过LAMP架构迅速搭起网站框架。随着业务扩张、市场扩大，迅速发展成为6台Dell小型机的中型网站。现在花了三年，终于成为垂直领域的最大网站，计划中的数据中心，拥有Dell机架式服务器40台，总预算20万美金。

MSSQLServer。windows生态系统的产品，好处坏处都很分明。好处就是，高度集成化，微软也提供了整套的软件方案，基本上一套win系统装下来就齐活了。因此，不那么缺钱，但很缺IT人才的中小企业，会偏爱MSSQLServer。例如，自建ERP系统、商业智能、垂直领域零售商、餐饮、事业单位等等。

1996年，BillGates亲自出手，从Borland挖来了大牛Anders，搞定了C

Q5: sqlserver 在高并发的情况下 用什么事务隔离级别比较好

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。

对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。

尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

sqlserver事务性能的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于sqlserver 事务、sqlserver事务性能的信息别忘了在本站进行查找喔。