Blazor Server中TPT类型记录表格分页性能极差问题求助

解决TPT导致的LEFT JOIN和鉴别器问题 #

• 直接查询子实体表：既然采用TPT继承建模，不要通过DbSet<Notification>查询SmsNotification，直接使用DbSet<SmsNotification>。EF只有在多态查询时才会自动关联父表生成LEFT JOIN，纯子实体查询应该仅扫描子表。检查你的查询代码，是否误用了父类DbSet或包含了父类导航属性。
• 显式配置鉴别器：如果业务不需要多态判断，用Fluent API缩小鉴别器的影响：

  modelBuilder.Entity<SmsNotification>()
      .HasBaseType<Notification>()
      .HasDiscriminator<string>("Discriminator")
      .HasValue<SmsNotification>("SmsNotification");
  

  若完全不需要多态逻辑，可测试是否能移除鉴别器列（TPT通常依赖鉴别器，需验证兼容性）。

优化拖慢性能的Count查询 #

• 分区表+分区统计：给SmsNotification表按日期字段（如CreatedTime）创建分区，将每日数据隔离到单独分区。Count当日数据时，SQL仅扫描对应分区，无需遍历全表，大幅降低DTU占用。
• 创建带索引的统计视图：构建按日期聚合计数的索引视图，SQL会自动维护视图统计，查询count直接读取视图即可：

  CREATE VIEW vw_SmsDailyCount
  WITH SCHEMABINDING
  AS
  SELECT CONVERT(date, CreatedTime) AS DataDate, COUNT_BIG(*) AS Total
  FROM dbo.SmsNotification
  GROUP BY CONVERT(date, CreatedTime)
  GO
  CREATE UNIQUE CLUSTERED INDEX IX_vw_SmsDailyCount ON vw_SmsDailyCount(DataDate)
  

  该视图查询速度可达毫秒级，几乎不消耗DTU资源。
• 用近似计数替代精确值：若业务允许不需要精确页数（如显示“共约X条”），通过系统视图快速估算：

  SELECT SUM(row_count) AS ApproxCount
  FROM sys.dm_db_partition_stats
  WHERE object_id = OBJECT_ID('SmsNotification')
    AND index_id < 2
    AND CONVERT(date, CreatedTime) = CONVERT(date, GETDATE())
  

  误差在1-2%以内，且完全不占用查询资源。
• 精细化缓存：按日期缓存每日count值，比如用Redis存储SmsCount_20240520，过期时间设为当日24点。新增/删除数据时，直接对缓存值做增量加减，无需重新执行count查询。

替换低效的Skip/Take分页 #

• 改用键集分页：Skip在数据量大时会强制SQL扫描所有前置行，性能极差。换成基于唯一有序键（如CreatedTime+Id）的键集分页：

  // 上一页最后一条数据的CreatedTime为lastTime，Id为lastId
  var nextPage = await db.SmsNotification
      .Where(s => s.CreatedTime == DateTime.Today)
      .Where(s => s.CreatedTime > lastTime || (s.CreatedTime == lastTime && s.Id > lastId))
      .OrderBy(s => s.CreatedTime)
      .ThenBy(s => s.Id)
      .Take(20)
      .ToListAsync();
  

  这种分页无需查询总记录数，SQL直接定位起始行，执行效率大幅提升。Radzen表格支持自定义分页逻辑，可适配该模式。

数据库索引与DTU资源优化 #

• 添加覆盖索引：为CreatedTime和Id创建包含所有表格展示字段的覆盖索引，避免SQL回表查询：

  CREATE NONCLUSTERED INDEX IX_Sms_CreatedTime_Id
  ON dbo.SmsNotification (CreatedTime, Id)
  INCLUDE (PhoneNumber, Content, Status, 其他需展示字段)
  

  查询和分页时直接从索引获取数据，显著降低IO和DTU占用。
• 强制使用指定索引：若EF生成的查询计划未选用最优索引，用EF的UseIndex强制指定：

  var query = db.SmsNotification
      .Where(s => s.CreatedTime == DateTime.Today)
      .UseIndex("IX_Sms_CreatedTime_Id")
      .OrderBy(s => s.CreatedTime)
      .ThenBy(s => s.Id)
      .Take(20);
  

• 弹性DTU应对高峰：若每日数据高峰时段固定，临时升级Azure SQL的DTU tier（如从S7升至S9），高峰过后再降回原 tier，避免超时问题。

Blazor Server端细节优化 #

• 减少组件重渲染：给Radzen表格添加@key，或控制渲染条件，避免分页时整个组件重新渲染，减少不必要的查询请求。
• 查询节流：用户频繁切换分页或查询时，添加500ms延迟再执行查询，避免短时间内发送大量SQL请求耗尽DTU。

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