为什么 SQL Server 不使用并行执行计划来加载大表中的所有行？

Question

如果我用这个定义填充表格：

CREATE TABLE [dbo].[GpsData]
(
    [GpsDataID] [int] IDENTITY(1,1) NOT NULL,
    [UnitID] [int] NOT NULL,
    [Longitude] [float] NOT NULL,
    [Latitude] [float] NOT NULL,
    [GpsTimeStamp] [datetime] NOT NULL,
    [SpeedKmpH] [tinyint] NULL,
    [OdoKm] [float] NULL,
    [DataStatusID] [tinyint] NULL,
    [DateCreated] [datetime] NOT NULL,

    PRIMARY KEY CLUSTERED ([GpsDataID] ASC)
                WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
                      IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
                      ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

有 200 万行，我得到以下并行执行计划：

SELECT * 
FROM GpsData 
WHERE GpsDataID < 3000

并且为了

SELECT * 
FROM GpsData 
WHERE GpsDataID % 2 = 0 OR GpsdataID % 2 = 1

并且为了

SELECT * 
FROM GpsData 
WHERE Longitude > 1

但不适用于：

SELECT * FROM GpsData

对于最后一个，肯定可能有多个工作人员扫描表，每个人都返回一部分？

Answer 1

为 SQL Server 进行查询计划优化的人们已经这样做了超过四分之一个世纪，因此很有可能他们知道并行性不会帮助您的全表查询。

您的表没有任何 BLOB 或 CLOB（大对象），因此整个数据都存储在聚集主键中。满足您的查询只需按顺序扫描集群主键、格式化数据并将其从网络连接推送到客户端软件。 瓶颈是存储 IO（读取 CPK）和网络 IO（推送数据），并且 CPU 并行性似乎无法帮助解决这些瓶颈。

在 SSMS 中，右键单击查询窗口并选择“显示实际执行计划”。你会学到很多东西。