The SQL Server Profiler page helps capture and inspect recent SQL activity for troubleshooting slow queries, unexpected workload, and application behavior.
When To Use Profiler
Use Profiler when live activity is moving too quickly, when you need event-style detail, or when you want to compare recent statements with Cached SQL and Query Store.
Typical Uses
- Review recently executed SQL.
- Identify expensive or repeated statements.
- Investigate application-generated queries.
- Capture slow-query patterns.
- Support performance tuning work.
Workflow
- Open the SQL Server.
- Select Profiler.
- Review recent statements and event details.
- Filter or sort by time, duration, reads, writes, or CPU where available.
- Open query detail and execution plan views where supported.
How To Use SQL Server Profiler
Use SQL Server Profiler when you need short-window statement evidence and live activity is changing quickly. It can help capture application-generated SQL around a user complaint, deployment, job run, or intermittent slowdown. Profiler is especially useful before you know which cached query or Query Store entry to inspect.
Profiler evidence should be treated as current context, not the whole performance story. A statement seen during the capture window may be important because of timing, but SQL Server Queries and SQL Server Query Store help show long-term cost, frequency, and plan behavior. If the captured statement appears blocked or delayed, compare with SQL Server Waits and SQL Server Activity.
Capture enough detail to identify the workload, then move to lower-noise pages for deeper analysis.
When captured statements include plan XML, use the execution plan viewer to inspect the selected statement and expensive operators. This helps turn short-window profiler evidence into a concrete query tuning question.
SQL Server Profiler FAQ
When should I use Profiler instead of Query Store?
Use Profiler for recent event-style context. Use Query Store for historical runtime, plan, and regression analysis.
Can Profiler identify the root cause by itself?
Sometimes it identifies the statement involved, but root cause usually needs waits, plans, indexes, or application context.
What should I record from a profiler review?
Record statement text, time, duration, reads, writes, CPU, application context, and related alerts.