怎样查出SQLServer的性能瓶颈

硬件性能瓶颈 内存 内存对SQL Server性能的影响胜过任何其他硬件。因此，对SQL Server系统的内存使用情况进行定期监视以确保内存的可用百分比高于20%是很有必要的。如果用户遭遇性能问题，同时可用内存百分比低于20%，那么此问题一定是内存分配不足导致的。这要求技术人员密切关注显示平均页面预期寿命的性能计数器，并确保平均页面预期寿命总是高于300秒（5分钟）。一旦放生少于此标准的情况，就说明要么是糟糕的索引设计导致了磁盘输入/输出（I/O）的增加，要么就是对内存的利用效率很低，或者是实际的内存不足。技术人员需要监视SQL Server系统上的分页率，并确保它们常规为1000页每秒。检查PerfMon object MSSQL Buffer Manager（性能监视对象MSSQL缓冲管理器）和Memory Performance Counters（内存性能计数器）。 同样，还要监视计数器，即PerfMon object SQL Server Memory Manager Counters中的Memory Grants Pending。此计数器显示的是每秒钟等待工作负载分配的进程总数。一般来讲，小型OLTP事务不需要大内存分配。对一个OLTP事务来说，任何大于零的内存分配都说明SQL Server系统存在内存不足。 解决内存瓶颈的途径之一是找出内存高耗进程，这可以确认诸如内存泄漏之类潜在的应用程序问题。你还可以通过检查查询优化性能以消耗更少的内存。另外一种方法就是给SQL Server增加更多的物理内存来扩展升级SQL Server环境。扩展升级通常是解决任何与内存相关的性能瓶颈的济世良方。 磁盘I/O使用 对比其他的硬件资源，存储输入/输出通常是SQL Server中最慢的系统资源。因此，监视存储系统以确定存储是否成为一个影响性能的瓶颈是十分重要的。如果是，那么下个步骤就是要调查是否能够优化存储系统的设计和配置以获得扩展性和高性能。检查Average Disk Sec/Read（秒均磁盘读取）和Average Disk Sec/Write （秒均磁盘写入）的PerfMon磁盘计数器。确保OLTP系统和更高决策支持系统的一个读或写的时间在理想情况下少于12毫秒。 与内存一样，解决磁盘I/O性能瓶颈最简单的方法就是扩展升级SQL Server环境，即用更快的磁盘替换现有磁盘，可以更好地应对I/O负载和分配I/O负载到多个轴上。同时还要定期整理磁盘数据。 CPU CPU性能瓶颈的发生有诸多原因。它们包括非理想的查询计划，应用程序或是数据库的设计缺陷，糟糕的SQL Server配置或是硬件资源的不足。技术人员可以对Processor Queue Length（处理器队列长度）的PerfMon operation system CPU（PerfMon *** 作系统CPU）和处理器计数器进行检查以验证正在等待CPU周期的线程数在八个以内。如果这一数字大于12，那就意味着CPU产生了性能问题。 在确认了某个CPU瓶颈之后，便可以使用sysdm_os_wait_stats动态管理视图（DMV）来确认对CPU来说排前十的性能最差的查询，如下所示。 SELECT TOP 10 (atotal_worker_time / aexecution_count) AS [Avg_CPU_Time] ,Convert(VARCHAR, Last_Execution_Time) AS [Last_Execution_Time] ,Total_Physical_Reads ,SUBSTRING(bTEXT, astatement_start_offset / 2, ( CASE WHEN astatement_end_offset = - 1 THEN len(convert(NVARCHAR(max), bTEXT)) 2 ELSE astatement_end_offset END - astatement_start_offset ) / 2) AS [Query_Text] ,dbname = Upper(db_name(bdbid)) ,bobjectid AS 'Object_ID', B FROM sysdm_exec_query_stats a CROSS APPLY sysdm_exec_sql_text(asql_handle) AS b ORDER BY [Avg_CPU_Time] DESC 接着，你可以对这些查询和底层索引进行调优以解决CPU瓶颈。同时，对你的SQL Server进行配置以使用所有可用的CPU机器。你还可以通过添加额外的CPU或用更快的CPU升级一个新的服务器来扩展你的SQL Server系统。 数据库设计问题 高度规范化的数据库 糟糕的数据库设计会导致数据库性能不足。例如，高度规范化的数据库是与复杂关系连接相关联的。这就造成了长时间执行查询对诸如CPU，内存，和磁盘I/O之类系统资源的浪费。显然，一个高度规范化的数据库会让SQL Server和数据库性能显著降低。编写高效查询的一般规则就是如果一个 *** 作需要五个或者更多的表连接，就要对数据库进行重新设计。 重复和未使用的索引 索引是解决很多性能问题的杀手锏，但是在频繁更新的表上拥有过多的索引会招致额外开销，因为SQL Server在执行插入/更新/删除 *** 作期间会执行额外的工作以保持索引处于最新状态。这就意味着在更新基于索引数量和复杂度的表中数据的时候，SQL Server数据库引擎需要更多的时间。同时，索引维护也会增加CPU和I/O使用，这会在一个密集写入的系统中对性能造成损害。因为任何重复和冗余的索引对系统资源来说毫无意义，所以需要将它们移除。

2008年，SIGMOD的一篇论文对面向磁盘的数据库性能开销做了分析⌄把整个数据库系统的开销做了统计。分析发现典型的数据库环境中实际上只有12%的资源是在真正处理业务查询和处理逻辑。其中30%用于缓冲区管理，30%处理数据并发控制管理的开销（Locking和Latching），28%处理数据库日志的处理（Logging）。如何降低这些数据库额外开销是考虑的重点方向。建议题主多关注行业公众号，比如 柏睿数据

RAID0已经是读写很好的RAId模式了，要想再提高性能，可以在raid卡 和 磁盘上想想办法，更高速的硬盘和磁盘控制器可以解决你的问题；你也可以考虑修改一下你数据库语句，尽量减少不必要的I/O访问。

　通过对大数据产业链的分析，我们可以看到，在大数据产业链的各个生产环节中，各大公司都已开占位，随着高性能计算机、海量数据的存储和管理的流程的不断优化，技术能够解决的问题终将不会成为问题。我们认为，真正会制约或者成为大数据发展和应用瓶颈的有三个环节：

第一、数据收集和提取的合法性，数据隐私的保护和数据隐私应用之间的权衡。

德勤认为，未来很多大数据业务在最初发展阶段将会游走在灰色地带，当商业运作初具规模并开始对大批消费者和公司都产生影响之后，相关的法律法规以及市场规范才会被迫加速制定出来。可以预计的是，尽管大数据技术层面的应用可以无限广阔，但是由于受到数据采集的限制，能够用于商业应用、服务于人们的数据要远远小于理论上大数据能够采集和处理的数据。数据源头的采集受限将大大限制大数据的商业应用。

第二、大数据发挥协同效应需要产业链各个环节的企业达成竞争与合作的平衡。

大数据对基于其生态圈中的企业提出了更多的合作要求。如果没有对整体产业链的宏观把握，单个企业仅仅基于自己掌握的独立数据，无法了解产业链各个环节数据之间的关系，对消费者做出的判断和影响也十分有限。

以上就是关于怎样查出SQLServer的性能瓶颈全部的内容，包括:怎样查出SQLServer的性能瓶颈、当磁盘I/O不再是瓶颈，内存数据库要考虑什么问题、2硬磁盘组成RAID0阵列，如何解决数据库访问时的IO瓶颈等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！