【发布时间】：2010-10-11 20:40:00
【问题描述】：
我有一个查询在交易过程中需要很长时间。当我得到进程的wait_type 时，它是PAGEIOLATCH_SH。
这种等待类型是什么意思，如何解决？
【问题讨论】：
标签： sql-server tsql optimization
【发布时间】：2010-10-11 20:40:00
【问题描述】：
PAGEIOLATCH_SH当任务正在等待
I/O请求中的缓冲区的闩锁时发生。锁存请求处于共享模式。长时间等待可能表明磁盘子系统存在问题。
在实践中，这几乎总是由于对大表进行大量扫描而发生。在高效使用索引的查询中几乎不会发生这种情况。
如果你的查询是这样的：
Select * from <table> where <col1> = <value> order by <PrimaryKey>
，检查您在(col1, col_primary_key) 上是否有复合索引。
如果您没有，那么如果选择了PRIMARY KEY，则需要完整的INDEX SCAN；如果选择了col1 上的索引，则需要SORT。
它们都是非常磁盘I/O 消耗大表上的操作。
【讨论】：
-
这是一个非常简单的查询。 Select * from
where
= order by 。我们在 col1 上也有一个索引，并尝试重建索引。 您能否推荐一些资源来帮助您了解什么是磁盘密集型、什么需要全索引扫描、什么需要排序等@GregB：如果您已经具备 SQL 的基本知识，您可以阅读 Joe Celko 的书（所有这些书，但尤其是SQL for Smarties和Thinking in Sets）当然还有我的博客 :)跨度>这确实表明我们的磁盘子系统存在错误。 RAID 磁盘发生故障而未触发监控系统。检查事件日志发现 SMART 确实将驱动器标记为损坏。
PAGEIOLATCH_SH 等待类型通常是由于索引碎片或未优化而出现的。
PAGEIOLATCH_SH 等待类型过多的常见原因是：
- I/O 子系统有问题或配置错误
- 产生高 I/O 活动的其他进程使 I/O 子系统过载
- 错误的索引管理
- 对逻辑或物理驱动器的误解
- 网络问题/延迟
- 内存压力
- 同步镜像和 AlwaysOn AG
为了尝试解决具有高 PAGEIOLATCH_SH 等待类型，您可以检查：
- SQL Server、查询和索引，通常这可以作为过多的
PAGEIOLATCH_SH等待类型的根本原因发现 - 在进行任何 I/O 子系统故障排除之前解决内存压力问题
请始终牢记，在 AlwaysOn AG 中的高安全性镜像或同步提交可用性的情况下，PAGEIOLATCH_SH 可能会增加/过多。
您可以在文章Handling excessive SQL Server PAGEIOLATCH_SH wait types中找到有关此主题的更多详细信息
【讨论】：