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

会不会是连接池问题

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

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

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

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

排查一下网络状况？

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

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 内存，依次类推(可以适当扣除一些基本不会用到的数据库数据)。

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