小编lon*_*und的帖子

我在Azure数据库中有一个表,它已经开始慢慢地对查询做出响应.查询看起来像:

SELECT [Id] --nvarchar(128), PrimaryKey
      ,[Name] --nvarchar(max)
      ,[Description] --nvarchar(max)
      ,[Modified]  --datetime2(7)
      ,[LastModifiedBy] --nvarchar(max)
      ,[Opened]  --datetime2(7)
      ,[Editor] --nvarchar(max)
      ,[Json] --nvarchar(max)   <--THIS IS GIVING ME PROBLEMS
      ,[IsActive] --bit
  FROM [dbo].[TableName]

具体来说,当我在查询中包含[Json]列时,SQL查询性能从不到一秒钟变为几分钟.当包含[Json]列时,即使仅请求单个记录也可能需要几分钟.此列包含长json格式的字符串(~500000个字符).当包含此列时,性能仅会中断 - 包含较小字符串的其他NVARCHAR(max)列不是问题.

我通过使用Entity Framework linq-to-entities查询的MVC5应用程序的性能问题发现了这个问题:

var model=await db.TableName.FirstOrDefaultAsync(s => s.Id == id);

它产生了一个类似上面的SQL查询.在本地开发机器上运行没有问题的单个案例的Edit方法在服务器上加载需要几分钟.然后我研究了直接的数据库查询,看看问题是什么,并找到了长查询时间.

在不同的查询方法中,此性能问题并不一致.

通过以下查询,我的周转时间为3分钟:

SELECT Json FROM [dbo].[TableName] WHERE [Id]=<id>

周转时间与返回的字符串长度成指数比例.例如,此查询大约需要10秒钟:

SELECT SUBSTRING(Json,1,50000) FROM [dbo].[TableName] WHERE [Id]=<id>

服务器上的查询如下所示:不到一秒钟:

DECLARE @variable nvarchar(max);
SELECT @variable=Json FROM [dbo].[TableName] where Id='<id>';
SELECT LENGTH(@variable);

但实际上如下所示检索数据会让我回到几分钟:

DECLARE @variable nvarchar(max);
SELECT @variable=Json FROM [dbo].[TableName] where Id='<id>';
SELECT …