1，数据的IO操作
SQL Server访问的任何一个Page必须存在于内存中，如果不存在于内存中，那么SQL Server发出 Disk IO请求，将数据页从Disk读取到内存中，然后SQL Server从内存中读取该Page的内容。在访问任何一个内存page之前，必须申请和获取该Page上的Latch。
在数据读取的过程中，SQL Server先在内存中预留一个Page的空间，并设置该Page的位BUF_IO=1，并发出Disk IO请求，此时，在该Page上加的Latch是PageIOLatch_EX，表示正在将数据页从Disk读取到内存。
在数据页加载的过程中，任何一个读取该Page的Thread，在该Page上加的Latch是PAGEIOLATCH_SH，表示在SQL Server Engine从Disk读取数据页，写入内存时，Thread试图读取该Page，由于PAGEIOLATCH_SH和PageIOLatch_EX不兼容，读取该Page的Thread会被Block，直到Page被读取到内存中。
一旦数据页被写入到内存中，PageIOLatch_EX会立即释放，并设置该Page的位BUF_IO=0。由于数据页存在于内存中，对该Page申请的Latch是PageLatch。
如果发生PAGEIOLATCH类型的等待，那么SQL Server一定是在等待Disk I/O操作的完成。如果经常出现这类等待，说明磁盘速度不能满足要求，已经成为SQL Server的瓶颈。PAGEIOLATCH_XX主要分为两大类：PAGEIOLATCH_SH和PAGEIOLATCH_EX。
PAGEIOLATCH_SH 发生在用户访问一个数据页，同时SQL Server正在将数据页从磁盘写入内存，经常发生PAGEIOLATCH_SH等待，说明内存不够大，导致SQL Server需要做很多页面读取的操作，磁盘IO是内存压力的副作用。
PAGEIOLATCH_EX：发生在从Disk page读取到内存buffer中，经常发生PAGEIOLATCH_EX等待，说明Disk读取速度慢，这和内存没直接关系。
2，数据页成为HotPage
当一个Task要修改页面时，它必须先申请一个EX的Latch，即PageLatch_EX。只有获取到Latch，才能修改页面的内容。由于数据页的修改都是在内存中完成，所以时间应该非常短，可以忽略不计。而PAGELATCH_EX只是在修改过程中才出现，所以生存周期应该很短，如果出现了，说明：1、SQL Server没有明显的内存和磁盘瓶颈。2、应用程序发出大量的并发语句修改同一张表，而修改操作集中在同一个页面，或者数量不多的几个页面上，成为Hot Page。3、这种瓶颈无法通过提高硬件配置解决，只能修改 Table的存储，使修改分散在更多的Page上，提高并发修改的能力。
Hot page的缓解方法：
（1）、换一个数据列建聚集索引，而不要在Identity字段上，同一时间插入有机会分散到不同的页面上。
（2）、如果一定要在Identity的字段上建聚集索引，建议在其他某个列上创建若干个分区。
（3）、为FileGroup增加File，尽量将Files分布在不同的Physical Disk上。
3，在tempdb中，系统Page成为Hot Page
SQL Server不仅在数据页面上加Latch，而且在数据文件的系统页面上，例如SGAM、PFS和GAM页面等，也会加Latch。系统Page有时候也会成为系统瓶颈。
在创建新表时，SQL Server 需要分配空间。分配存储空间需要同时修改SGAM、PFS和GAM页面，设置标识位，由于一个系统Page的标志位管理很多数据页，当频繁的创建和删除表结构时，而这些数据页都发生在同一个系统Page，或者数量不多的几个系统Page上，会使该系统Page过热，成为Hot Page。在tempdb中，创建和删除table结构的操作会并发、反复发生，容易使系统页过热，产生hot Page。系统page过热，可以通过调整表设计来缓解。对此的解决方法：
- 建立与cpu数量相同的tempdb文件，保持File Size相同，使得每个File承担的IO压力相对平均
- 禁止 tempdb 文件自动增长，避免单个文件不平均增长