带分页的动态SQL查询性能优化问题咨询

让我来帮你拆解这个性能问题——我之前处理过类似的千万级用户表查询优化，结合SQL Azure的特性，给你几个针对性的方向：

1. 优先排查索引是否匹配查询模式 #

这是最常见的性能瓶颈点。你的查询是双条件组合（比如邮箱+姓氏、公司+其他字段），如果没有对应的复合非聚集覆盖索引，数据库大概率在做全表扫描或者键查找，这对百万级表来说肯定慢。

• 针对每个常用的查询组合创建复合索引，比如：

  CREATE NONCLUSTERED INDEX IX_Users_Email_LastName 
  ON Users (Email, LastName)
  INCLUDE (UserId, Company, [其他查询需要返回的字段]);
  

  用INCLUDE列把查询需要返回的字段加进去，避免“书签查找”（Bookmark Lookup），让数据库直接从索引里拿到所有需要的数据。
• 注意：如果查询条件的字段顺序经常变化（比如有时候是姓氏+邮箱，有时候是邮箱+姓氏），可能需要创建两个索引，或者考虑列存储索引（OLTP场景下需谨慎评估）。
• 定期检查索引碎片：因为数据增长快，索引碎片会影响性能，可以用sys.dm_db_index_physical_stats查看，必要时重建或重新组织索引。

2. 分析执行计划找耗时点 #

不要盲猜，直接看执行计划就能精准定位问题：

• 在SSMS或者Azure Portal的查询编辑器里，打开“Include Actual Execution Plan”，运行你的存储过程/视图，重点关注以下耗时操作：
  • 全表扫描（Table Scan）：说明没有匹配的索引
  • 键查找（Key Lookup）：需要补充INCLUDE列或调整索引结构
  • 排序（Sort）：如果查询含ORDER BY但索引未覆盖排序字段，会额外消耗CPU和内存
• 也可以用SQL Azure的Query Performance Insight功能，它会自动识别慢查询的瓶颈（比如IO、CPU消耗占比）。

3. 检查存储过程/视图的逻辑冗余 #

你提到需要执行两次，会不会是存储过程里有重复查询逻辑？或者视图设计过于复杂？

• 存储过程：有没有参数嗅探问题？SQL Azure有时候会因参数嗅探生成不合适的执行计划，你可以试试在查询末尾加OPTION (RECOMPILE)，或者用局部变量接收参数再查询：

  DECLARE @Email NVARCHAR(255) = @InputEmail;
  DECLARE @LastName NVARCHAR(50) = @InputLastName;
  SELECT * FROM Users WHERE Email = @Email AND LastName = @LastName OPTION (RECOMPILE);
  

• 视图：有没有不必要的JOIN？比如关联了非必需的表，或者用SELECT *返回过多字段，尽量只查询业务需要的列。

4. 考虑数据分区优化 #

因为你的数据每年新增100-200万，用户表可以按创建日期或注册年份做分区，这样查询时数据库只需要扫描相关分区，大幅减少IO量。

• SQL Azure支持表分区，你可以创建分区函数和分区方案，把不同年份的数据放在不同分区里，查询时如果能过滤分区键，性能会有明显提升。

5. 利用Azure SQL的自动优化功能 #

SQL Azure P11实例支持自动优化，开启后它会自动帮你：

• 创建缺失的索引
• 删除冗余的索引
• 修复有问题的查询执行计划
  你可以在Azure Portal找到目标数据库，进入“Query Performance Insight” -> “Automatic tuning”开启这些功能，这是零成本的优化手段。

6. 验证缓存对性能的影响 #

你说执行耗时约15秒（需执行两次），第一次执行可能是冷缓存（数据不在内存），第二次是热缓存？可以做个简单测试：

• 先执行一次查询，再重复执行一次，看第二次耗时是否明显降低。如果是，说明主要瓶颈是IO，可以考虑调整存储配置（P11已是Premium SSD，可评估是否需要扩容存储）或优化缓存命中率。

内容的提问来源于stack exchange，提问作者James Legan