在Entity Framework的CRUD操作前执行SELECT标记语句是否会引发性能问题？

我们的应用此前出现过单条查询耗时20秒的性能问题，通过Azure Data Studio定位到慢SQL后，最终溯源到对应的Entity Framework执行语句。我计划在代码中新增日志函数，在Entity Framework执行insert、select、delete、update等所有数据访问操作前，先执行一句Select user_functionname_now SQL语句，这样就能在Azure Data Studio Profiler中查看对应函数的执行耗时，方便定位慢查询对应的代码位置。
随后在Azure Data Studio Profiler中可看到如下内容：

该截图显示用户执行了加载发票函数，耗时2717毫秒。即便应用有100个用户同时操作导致日志部分混淆，该方案也能大幅提升慢查询对应代码位置的定位效率。
我也曾考虑过为每次执行的查询新增一个固定列，效果如下：

但该方案的问题在于每次查询都会返回额外数据，增加SQL Server与应用程序之间的数据传输量，显然不是合理方案。

新增标记SELECT方案的合理性评估 #

这个方案不是完全不可用，但存在多个未被考虑到的风险，不建议全量开启：

• 额外数据库往返开销：每次CRUD操作多一次独立的数据库请求，即使单条语句执行耗时只有1ms，高并发场景下累积的开销会非常可观：会额外占用数据库连接池配额、增加网络IO消耗，甚至拉高数据库实例的CPU使用率，反而加重性能问题。
• 事务干扰风险：如果你的CRUD操作在显式事务中执行，这条额外的SELECT会被纳入事务范围，延长事务持有锁的时长，提升死锁发生的概率。
• 日志错位风险：在连接池复用的场景下，高并发时标记语句和后续CRUD语句可能被分配到不同的数据库连接执行，Profiler中无法保证两条语句的对应关系，反而会误导问题定位。

更优的替代方案 #

Entity Framework本身内置了SQL拦截能力，完全不需要额外发送标记SQL就能实现你的需求：
你可以通过实现DbCommandInterceptor拦截所有EF生成的SQL执行，在拦截逻辑中将业务方法名、调用栈、TraceID等你需要的标记信息，以注释的形式拼接在SQL语句最前方。最终生成执行的SQL会是如下形式：

-- 方法名:LoadInvoices, 用户ID:123, TraceId:xxx
SELECT * FROM Invoices WHERE UserId = @p0

这种方案没有额外的数据库请求，也不会增加结果集传输量，你在Azure Data Studio Profiler中可以直接看到每条SQL对应的业务标识，定位效率和你原方案一致，没有额外副作用。
如果仅用于排查问题，也可以直接开启EF的内置日志，将SQL执行耗时、生成的SQL直接输出到应用日志中，关联TraceId后可以直接对应到业务请求，不需要查询数据库Profiler。

原方案的降级使用建议 #

如果你坚持要使用新增标记SELECT的方案，建议做如下优化降低影响：

• 不要全量开启，仅在预发布环境开启，或者生产环境仅做抽样开启（比如1%的流量），排查特定问题时临时调高抽样比例。
• 标记SELECT不要放在事务内执行，避免延长事务周期。

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