sql-server - 向 SQL 发送“Select functionname001”以轻松识别长时间运行的查询以及从何处调用
问题描述
我们的应用程序中的一个查询存在性能问题,需要 20 秒才能运行。使用 azure data studio,我们找出了长时间运行的 SQL,然后最终将其追溯到执行的实体框架查询。
我有一个想法,在我们的代码中添加一个日志记录函数,在实体框架代码中完成任何数据访问(插入、选择、删除、更新等)之前调用它。
该函数的作用是简单地执行“Select user_functionname_now”sql 语句。
然后在 azure data studio profiler 中我们会看到:
图片告诉我,用户运行了加载发票功能,耗时 2717 毫秒。
当然,如果您有 100 个用户在应用程序中执行操作,那么日志可能会有点混乱,但要弄清楚长时间运行的查询是从代码中的哪个位置执行的,这将有很长的路要走。
我还想我们可以为每个查询运行添加一个固定列,以便您可以看到如下内容:
但是添加列的问题是每次运行查询时都会返回额外的数据,这需要在 SQL 服务器和应用程序之间来回传递更多数据,这肯定不是一件好事。
所以我的问题是:在每次 CRUD 调用之前添加“选择 XYZ”是不是一个坏主意?如果我们将此日志记录调用添加到执行查询的部分或全部代码中,是否会导致我没有考虑过的性能问题/减速?
解决方案
这就是 EF查询标签适用的场景。
推荐阅读
- multithreading - 如何让我的应用程序在多个内核上运行?
- c# - 显示在 EF Core 存储库中创建的异常,而不是 500 错误
- visual-studio - 检查解决方案文件夹是否包含不属于解决方案的文件
- ms-access - 需要使用用户名、密码和系统 DB 更改 MS Access DB 中的链接表
- python-3.x - GlfwError: 无法创建 GLFW 窗口 (windows)
- python - 更新插件需要重新安装 Orange3
- java - 通过 Maven 为 Spring Boot 应用程序创建 AWS Beanstalk 的 .ebextensions 的正确方法是什么
- java - Java hibernate SQL Null 点异常
- angular - 在异步中使用 Promise 时捕获 HTML5 FileReader 的结果
- javascript - 获取 beforeEach 以仅在它所在的文件中运行测试