小编Jam*_*gan的帖子

我面前有一个有趣的问题。有一个数据库有大约 100 万个用户帐户，预计每年增长 1-200 万个。该数据库是强 TPT，但此特定查询和所涉及的表不涉及任何 TPT 内容。

当指定第二个数据点（即电子邮件地址和姓氏、公司等）时，sproc 和视图的当前设计需要大约 15 秒来执行 (x2)。该数据库是 SQL Azure P11，但它不是 DTU 绑定查询，升级到最高可用产品 (P15) 对结果没有影响。

下面是 sproc、视图和执行计划。在过去 24 小时内重建或重组了所有索引，并更新了所有统计信息。例如，在查看数据时，历史电子邮件地址 (1..N) 的概念目前正在使用 aCROSS APPLY来获取最新的，这可以防止索引视图，可以通过简单地连接历史电子邮件地址和持久化来解决它们在一个列中。

许多数据库在 nvarchar(4000-max) 列中使用 JSON，所有这些列都有一个公开值并启用索引的计算列。范式必须支持分页，我正在寻找有关如何优化它的反馈/建议。

在这一点上，更改表结构不是一个可行的选择，尽管我可以通过一点点操作看到前进的道路。有没有人对我应该首先看哪里有任何想法？我已经对未知的重新编译和优化进行了测试，以查看是否有任何影响，如果有，则可以忽略不计。

注意：一些业务逻辑（专有列名被删除或修改，sproc和view不能按原样执行，但在功能上与源相同。

执行计划和视图

程序

CREATE PROCEDURE [dbo].[spGetUserDetailsDynamic] @JsonFilter NVARCHAR(MAX)
AS /* Page number*/
DECLARE @Page AS INT = JSON_VALUE(@JsonFilter, '$.requestPaging.page');
/* Number of records on the page*/
DECLARE @Size AS INT = JSON_VALUE(@JsonFilter, '$.requestPaging.size');

IF (@Page = -1)
    SET @Page = 1;

IF (@Size …