在很多时候,我们需要优化接口的执行效率,一方面是提高代码在内存中的执行效率,另一方面就是提高数据库操作相关的效率了。
.NET中在System.Diagnostics
类库下提供了Stopwatch
类用来分析代码的执行耗时。那么如果是牵扯到数据库相关的操作,我们可以利用SSMS自带的分析工具,来查看进来的每一条sql语句的执行时间,以此来定位问题。
首先打开SSMS,选择工具>SQL Server Profiler。打开SQL Server Profiler的登录页面。用连接数据库的登录名和密码进行登录即可。
打开之后需要设置一下跟踪属性,其中常规里,可以设置把跟踪记录导出到文件或者表,如果为了方便仔细分析,可以选择保存到文件,之后停止跟踪的时候,就会生产一个.trc
文件,之后在SQL Server Profiler在打开这个文件,就可以慢慢分析了。
在事件选择里,可以选择跟踪哪些事件,以及列名。
但是这里有一个问题,这个跟踪的是整个服务里面的所有数据库,如果数据库比较多,或者连接比较活跃的话,那跟踪记录就会不断的刷新,就不容易找到关键信息。
所以我们现勾选显示所有列。然后点开列筛选器。在这里输入DatabseID或者DatabaseName都可以定位到某一个数据库,获取DatabseID的SQL语句
--查看当前数据库的id
SELECT DB_ID()
然后就可以开始观察了。重点需要关注的一个是说TextData
,这里是我们执行过的所有SQL语句,另一个是Duration
,这个表示执行sql的耗时。如果有耗时特别夸张的就可以分析sql语句是不是可以优化,通过添加索引等方式来减少SQL语句的执行时间。
我下面把其他列名的含义也都列一下。
字段 | 含义 |
---|---|
TextData | 包含执行的SQL语句或存储过程的文本。这是分析查询性能时最关键的列之一。 |
StartTime 和 EndTime | 分别表示事件开始和结束的时间戳。这两个时间戳对于分析查询执行时间和识别并发问题非常有用。 |
Duration | 表示事件(如SQL语句执行)持续的时间,通常以微秒为单位。这个值对于识别性能瓶颈至关重要 |
CPU | 表示事件(如SQL语句执行)消耗的CPU时间,通常以毫秒为单位。它反映了查询在CPU上的执行效率 |
Reads 和 Writes | 分别表示事件执行期间从磁盘读取和写入的数据量(以逻辑读取和写入次数为单位)。这两个值对于评估查询对I/O的影响很重要。 |
SPID | 表示执行该事件的服务器进程ID。它可以帮助识别哪个客户端会话或进程产生了特定的数据库活动 |
LoginName | 执行事件的登录名。这有助于识别是哪个用户或应用程序导致了特定的数据库活动 |
ApplicationName | 发起数据库活动的应用程序的名称。这有助于将数据库活动与特定的应用程序或工具关联起来 |
DatabaseName | 事件发生时所在的数据库名称。这有助于了解哪个数据库受到了影响 |
ObjectName 和 ObjectType | 分别表示事件涉及的对象名称和对象类型(如表、视图、存储过程等)。这对于识别哪些数据库对象被查询或修改非常有用。 |
EventClass | 表示事件的类别,如SQL:BatchStarting、SQL:BatchCompleted、Login等。这个列帮助用户识别追踪文件中各种事件的类型。 |
EventSubClass | 提供了EventClass的进一步细分,以提供更具体的事件信息。 |
Status | 表示事件的状态,如成功、失败等。这有助于识别执行过程中是否出现了问题 |
Error | 如果事件执行失败,则此列将包含错误代码和消息。这对于诊断问题非常有帮助 |
study hard and make progress every day.