讨论四：运行的MSSQL系统突然变慢了，应该如何去排查

[开着拖拉机泡妞]

welcome 魔君


继续

.
.
.
.
.
.
.
.
.
.

[岩崽先生]

引用 1 楼 TravyLee 的回复:

开个头，这个问题大致可以在两个方向讨论： 第一：硬件 第二：如果排除了硬件问题，那么如何定位MSSQL系统中室何原因造成的系统变慢？ 第三:如何解决这些问题？

cc 对应你的第一 换硬件 第二 清理垃圾或者买个正版的 第三 综上

• 打赏
• 举报

回复 赞

[熊猫王子]

索引？ 死锁？

• 打赏
• 举报

回复 赞

[_KyLeo]

才刚学完数据库，没了解到那么多，不过看完楼下的回复，感觉和平时操作系统变慢的原因差不多

• 打赏
• 举报

回复 赞

[孤云-疯子]

么么，那么多原因，记不住啊··

• 打赏
• 举报

回复 赞

[流氓兔]

太多了，如果最近才变慢，，那就找最近的业务，进行分析

• 打赏
• 举报

回复 赞

[yyd3642905]

过来看看，学习学习

• 打赏
• 举报

回复 赞

[dfdsfdsfsfsafsdfsdf]

mark SQL_beginner

• 打赏
• 举报

回复 赞

[zosky]

查看新建表，如果新建表没索引就加索引，本地数据库新发现的问题

• 打赏
• 举报

回复 赞

[rfq]

突然太慢， 其实 不用搞的太麻烦， 一般都是查询语句太复杂，计划没有利用索引 ，造成性能缓慢。 最好 看看查询计划

• 打赏
• 举报

回复 赞

[阳泉酒家小当家]

一般来说，sql server最主要的可能是某些sql语句运行很慢，因为本质上，sql server最大的功能，就是运行sql。

• 打赏
• 举报

回复 赞

[测试菜鸟]

mark，关注下

• 打赏
• 举报

回复 赞

[dullknife_forever]

我觉得要考虑I/0 的读写速度。 以及sql server 分配的内存。

• 打赏
• 举报

回复 赞

[flai]

最近也遇到这样的问题，mark.

• 打赏
• 举报

回复 赞

[hyena2009]

1,看用户是操作什么功能变慢了，找到对应的sql语句； 2，如果是数据库层问题，可以重建索引 dbcc reindex; 或者表重构：拆表；

• 打赏
• 举报

回复 赞

[Joylwu]

以下选自《Inside Microsoft SQL Server 2008: T-SQL Querying》 使用自顶向下方法的优化论。这种方法首先分析实例级的等待时间，再通过一系列步骤将其不断细化，直到找出系统中导致大量等待的进程/组件。一旦找出这些令人讨厌的进程， 就可以集中优化它们了。以下是这种方法论的主要步骤： 1. 分析实例级别的等待 优化方法论的第一步是在实例级别上找出什么类型的等待占用了大部分的等待时间。这可以通过 查询动态管理图（DMV, dynamic management view)来完成。该 DMV 包含了400多种等待类型，大多数类型在SQL Server联机丛书中至少有一段简单的文字说明。如果考虑一下， 你会认为这个数暈还算是可以管理的等级，可以将这个DMV作为优化的起点。而其它一些性能工具 则不适合在开始时使用，因为它们提供的信息量太大，让你无从入手。 2. 关联等待和队列 在实例级找出重量级的等待之后，就应该把它们和队列关联起来，以找出有问题的资源。这一步主要是用性能监视器（PerformanceMonitor)的计数器来完成任务的。例如，如果在上一步找到的是 与I/O相关的等待，这时就应该检査不同的I/O队列、缓存命中率、内存计数器。平均在每个（磁盘） 转轴上的一个I/O队列中，正在等待的I/O命令不应该超过两个。缓存命中率应该尽可能要髙。 3. 确定方案 在找出主要等待类型和这些等待所涉及的资源之后，接下来的这一步是优化过程中承上启下的 —步，根据到目前为止所掌握的信息，你将确定下一步研究的行动方案。 4. 细化到数据库/文件级 优化处理的下一步是细化到数据库/文件级别。这一步要找出哪些数据库占用了大部分等待开销。在数据库内，还需要再细化到文件类型（数据/日志），因为文件的类型决定了要采取的行动方案。在数据库/文件级别分析I/O信息的一种工具是动态管理函数sys.dm_io_virtual_file_stats。这 个函数接受一个数据库ID和文件ID作为输入，返回与该数据库文件相关的I/O信息。如果将这两 个参数都指定为NULL，则返回关于所有数据库和所有文件的信息。 5. 细化到进程级 既然己经知道了哪些数据库导致了大部分性能问题，现在就应该继续细化到进程级别，也就是说，找出要优化的进程(存储过程、査询等)。对于这个任务，使用SQL Server内建的跟踪（tracing)功能特别方便。这一步要对工作负荷（workload,代表 正在关注的数据库在系统中的典型活动）进行跟踪，分析跟踪数据，并找出要优化的进程。 跟踪会影响系统的性能，应该尽量减少这种影响： ->不要使用SQL Server Profiler GUI进行跟踪； ->不要把跟踪数据直接写到表，这样会严重影响性能。把跟踪数据写到磁盘文件是最快的选择； ->跟踪会产生大量的数量和额外的I/O操作。不要把目标跟踪文件放到包含数据库文件（如数据、 日志和tempdb)的磁盘上。理想的情况是，为目标跟踪文件专门配置单独的磁盘驱动器； ->慎重选择事件类和数据列，只跟踪需要的佶息，移除所有默认的和不必要的对象； ->使用跟踪筛选功能，只选择相关的事件。 6. 优化索引/査询 现在己经知道了哪些査询模式需要进行优化，可以着手更具体的査询优化步骤了

• 打赏
• 举报

回复 赞

[wangnaisheng]

mark一下，学习~

• 打赏
• 举报

回复 赞

[gem227]

mssql主要是内存占用比较多，你可以做个计划任务定期释放下内存，这样就能缓解系统运行速度慢的问题！

• 打赏
• 举报

回复 赞

[Neo_whl]

学习，支持

• 打赏
• 举报

回复 赞

[还在加载中灬]

围观神贴!!

• 打赏
• 举报

回复 赞

[xiaoyao_98]

具体问题具体分析，应该从硬件、软件、系统等方面分析，

• 打赏
• 举报

回复 赞