疑难杂症：列表查询接口报错：操作超时

[Visitor233]

如果我能解决这个问题，给大伙发 500 块红包。

超时报错很频繁，峰值隔几十秒来一次，或者几分钟来一次。

1：sqlserver 2008r2,订单详情表和生产表都是 50 万行数据，300 多列，想过扩展事件记录 duration 超过 5 秒的 SQL ，但服务器上没有 evenfile 。查日志也没有 deadlock ，不清楚开了记录没。
查询 SQL 单独拿出来运行很快，秒查。

2：.net framework 4.6 web api ，没有报错日志

3：站点和数据库在同一台服务器上，CPU 稳定 20%至 50 ％，内存 80%，都未过载。

4：客户端 winform 程序也只有两台机器，车间人员手速操作挺快的。requeat 超时设置的是 60 秒。超时报错 50%都是卡在查询的 loading 函数里，没有增删改。

[wujb07]

会不会是连接池问题

[lasuar]

进一步定位 loading 函数里面的代码，是否查询有额外的数据处理逻辑；另一半超时在哪呢，50%是如何得出？

[wu00]

问 AI 呗，你需要的是排查思路。
先排查是客户端问题还是服务端问题，排查网关/服务端/客户端的请求响应日志
你连是客户端问题还是服务端问题都没说清楚，只知道卡在 loading ，你说是超时，那么有 504 超时响应么、服务端有 499 么

[asmoker]

loading 函数里一行代码一行日志，打印关键信息和耗时

[shangsharon]

在 web api 里加类似 miniprofiler 的组件记录接口执行时长,看能不能找到问题.

[daxin945]

排查一下网络状况？

[opengps]

关注下磁盘队列长度，并发可能读取量过大产生了队列等待

[yinmin]

sql server 用了几十年了，上千人同时使用的企业应用 sql server 完全没问题，一句 sql 查询跑几十分钟完全不影响其它用户读写的。

我估计大概率是程序写的有问题，检测步骤如下：
(1) 运行 SELECT session_id,connect_time,client_net_address,auth_scheme FROM sys.dm_exec_connections; 查询 connection 情况，如果同一个客户端连接数太多，说明代码写的有问题。
c#连数据库，SqlConnection 、SqlCommand 是必须要用 using 的，不用 using 会 connection 不释放，然后连接数超限就会卡死一段时间。（用法见： https://sanderrossel.com/using-c-to-connect-to-and-query-from-a-sql-database/ )。如果没有用 using ，必须重写代码加上 using ！！！

(2) 长时间的 SQL 语句，需要配置 Cmd.CommandTimeout 值，例如 1800 秒，避免超时。

(3) 查 sql 实时运行情况，是用 sql server profiler ，连上服务器配置条件后就能实时看到 sql 了。对于时间过长的 sql ，可以使用 sql server management studio 的"显示估计的执行时间"功能，在耗时大的地方看看是否需要加索引。

(4) 关键之关键：服务器内存必须大于数据库总容量的，找到 sql 数据库的 data 目录，mdf 文件合计大小算一下，直接*1.25 倍，就是应该服务器内存大小，如果 mdf 合计有 40GB ，服务器就要配置 64GB 内存，如果 mdf 合计有 100GB ，服务器就要配 128GB 内存，依次类推(可以适当扣除一些基本不会用到的数据库数据)。

[yinmin]

SQL Server 2008R2 安装补丁后，版本应该是 10.50.6220 ，如果是 10.50.1600 说明数据库运维是不合格的，原始版本一个补丁都没打。