极速快3_快3app赚钱_极速快3app赚钱

下单快发货慢:一个 JOIN SQL 引起 SqlClient 读取数据慢的奇特问题

时间:2020-02-08 22:25:54 出处:极速快3_快3app赚钱_极速快3app赚钱

更新:你什儿 问题报告 报告 是 System.Data.SqlClient 的三个 多多 bug 引起的,详见 坑暗花明:又遇 .NET Core 中 System.Data.SqlClient 查询缓慢的问题报告 报告

最近遇到三个 多多非常奇特的问题报告 报告 ,在三个 多多 ASP.NET Core 项目中从 SQL Server 808 R2 中查询获取 80 条记录竟然耗时 10 多秒,可能是查询四种 慢,那到都是哪些奇特的问题报告 报告 。

说它非常奇特是可能耗时主要存在在 SqlDataReader 读取数据时

2019-04-04 21:31:58.546 [Information] Executed DbCommand ("2,656"ms)
...
2019-04-04 21:32:10.690 [Debug] A data reader was disposed.

进一步测试发现

查询获取 1 条数据库记录,耗时在 280ms 左右  
查询获取 10 条数据库记录,耗时在 1.6s-2s 之间
查询获取 80 条数据库记录,耗时在 12s-22s 之间

开始英文英语 怀疑是 EF Core 的问题报告 报告 ,通过在 EF Core 源码中打点,定位到耗时存在在 _dataReader.ReadAsync 处

while (await _dataReader.ReadAsync(cancellationToken))
{
    _buffer.Enqueue(_valueBufferFactory.Create(_dbDataReader));
}

_dataReader.ReadAsync 实际调用的是 System.Data.SqlClient 中的 SqlDataReader.ReadAsync 最好的依据。

一次 ReadAsync 读取一行记录,通过在 SqlClient 的源代码中打点记录时间戳发现,在 80 次一行一行读取中,其含有好多个读取会出现延迟,比如某一次 13 秒延迟,80 次读取中出现了 5 次读取延迟 —— 2s + 3s + 3s + 2s + 3s = 13s 。

经过在 System.Data.SqlClient 源代码中无数次打点记录时间戳最终定位到延迟存在在  SNIPacket.ReadFromStreamAsync()  最好的依据中  stream.ReadAsync()  时

Console.WriteLine($"Entering stream.ReadAsync() at {DateTime.Now}");
stream.ReadAsync(_data, 0, _capacity, CancellationToken.None).ContinueWith(t =>
{
    Console.WriteLine($"stream.ReadAsync().ContinueWith at {DateTime.Now}");
    //...
}

stream 对应的是 NetworkStream ,延迟存在在网络传输过程中,与 SqlClient 没关系。

TCP 抓包发现 SQL Server 服务器发送的数据到达就延迟了。

于是没人将怀疑对象锁定在 SQL Server 数据库层面。

对应的 SQL 查询语句涉及 4 张表,FROM 一张表(表A), JOIN 三张表(LEFT JOIN 表B,LEFT JOIN 表C ,INNER JOIN 表D),表A有800多万条记录,表C有800多万条记录,查询时按表A的主键排序,表A的聚集索引建在时间字段上,没人建在主键上。

SELECT ...
FROM TableA
LEFT JOIN TableB ON [TableA].[Id] = [TableB].[EntryID]
LEFT JOIN TableC ON [TableA].[Id] = [TableC].[EntryID]
INNER JOIN TableD  ON [TableA].[BlogID] = [TableD].[BlogID]
WHERE ([TableA].[Id] >= @__startId_0)

并都是所有查询都出现你什儿 问题报告 报告 ,当 @__startId_0 小于一定值都是出现。

后来尝试将  LEFT JOIN TableC 改为 INNER JOIN TableC ,问题报告 报告 竟然消失了,但进一步测试发现当  @__startId_0  再小到一定值问题报告 报告 又会出现。

既然问题报告 报告 与 JOIN TableC 有关,那干脆不进行 JOIN ,单独查询 TableC ,否则将在 C# 代码中将查询的结果合并进行,从前改进了,查询获取 80 条记录只需 80 多毫秒。

你什儿 奇特的问题报告 报告 就从前用三个 多多简单粗暴有效的最好的依据临时防止了。

对于你什儿 问题报告 报告 的根本原因分析分析,怀疑与 TableA 没人把聚集索引建在 Id 字段上有关,但目前没人修改聚集索引进行验证,完后 再找可能验证。

热门

热门标签