如何提升60GB大表的SELECT查询性能？是否需使用分区表？
咱们先从最直接、成本最低的优化手段入手，再逐步考虑分区这类进阶方案：
1. 优化现有索引，消除回表开销
你当前创建的[ColumnA, ColumnB]复合索引是个好起点，但因为查询是SELECT *，SQL Server在通过索引找到符合条件的行后，还得回表（键查找）去获取ColumnC-G的值——这对于返回25万行的场景来说，额外的IO开销会非常大，直接拖慢查询速度。
解决办法是把这个索引改成覆盖索引，把所有需要返回的列都包含进去，这样查询可以直接从索引里拿到所有数据，不需要回表：
CREATE NONCLUSTERED INDEX IX_Table_ColumnA_ColumnB_Covering ON [table] (ColumnA, ColumnB) INCLUDE (ColumnC, ColumnD, ColumnE, ColumnF, ColumnG);
创建完这个索引后，再执行查询，应该能看到执行计划里变成了索引查找(非聚集)，没有了键查找的步骤，性能会有质的提升。
2. 更新统计信息，确保执行计划最优
SQL Server依赖统计信息来判断怎么执行查询最快，如果你的表数据量很大且有频繁的写入/更新，统计信息可能过时，导致生成的执行计划不是最优的（比如本来应该走索引，结果走了全表扫描）。
执行以下命令更新统计信息：
UPDATE STATISTICS [table] WITH FULLSCAN;
FULLSCAN会扫描全表生成最准确的统计信息，适合大表场景。
3. 处理参数嗅探问题
因为你的查询用了参数，可能存在参数嗅探的问题：SQL Server会根据第一次执行时的参数生成执行计划，后续如果参数范围变化很大（比如第一次查的范围很小，后来查的范围很大），之前的执行计划就不再适用，导致查询变慢。
可以在查询末尾加上OPTION (RECOMPILE)，让SQL Server每次执行都根据当前参数生成最优计划：
SELECT TOP 250000 * FROM [table] WHERE ColumnA > @parameter AND ColumnA < @parameter2 AND ColumnB > @parameter3 AND ColumnB < @parameter4 OPTION (RECOMPILE);
这个选项的开销很小，对于大查询来说完全值得。
4. 合理配置SQL Server内存
你的笔记本有16GB内存，要确保SQL Server能用到足够的内存来缓存数据，减少磁盘IO。打开SQL Server Management Studio，右键实例→属性→内存，把“最大服务器内存(MB)”设置为12288（也就是12GB），留4GB给Windows系统和其他进程，这样查询时更多的数据可以缓存在内存里，不用每次都读SSD。
5. 分区表与多磁盘文件组：是否需要？
分区表确实能提升大表的查询性能，但它是进阶方案，应该在前面的优化都做完后，性能还达不到要求时再考虑。
- 分区键选择：如果
ColumnA或者ColumnB的数据是有规律的范围分布（比如ColumnA是按批次递增的ID，或者有明确的分段逻辑），可以把它作为分区键，这样查询时只会扫描符合条件的分区，减少需要读取的数据量。 - 多磁盘文件组：把不同的分区放在不同的SSD磁盘上，确实能利用多磁盘并行读写的能力，进一步提升IO性能。但前提是你的笔记本有多余的SSD插槽或者外接SSD，否则这个方案不适用。
需要注意的是，分区表的管理成本较高（比如分区维护、备份恢复等），所以优先把前面的基础优化做好，再考虑这个选项。
内容的提问来源于stack exchange，提问作者Joao Rafael
