In SQL Server, a lot goes on behind the scenes when you execute a query or invoke a stored procedure. We'll use a special visual model to explain how SQL Server handles both.

The Four Primary Steps Each Query Takes
Whether it's an Normal SQL query or a stored procedure, SQL Server follows the same general flow.

  • Parsing: SQL Server checks for typos and turns your query into a tree structure it can understand.
  • Algebrizing: It links your query to actual tables and columns, and checks for things like permissions.
  • Optimization: SQL Server builds a plan for how it thinks the query should run choosing indexes, join types, etc.
  • Execution: It runs the plan and returns the results.

The Plan Cache: SQL Server’s Memory Trick
To save time, SQL Server stores execution plans in memory (called the plan cache). If a query or procedure has already been run, SQL Server can reuse that plan instead of making a new one.

  • Raw SQL Query: SQL Server saves each unique query. Even small changes (like a space or value) create a new plan.
  • Stored procedures: These are compiled once and reused, so they’re better at plan reuse.

Inside the SQL Server Engine
Let’s break down the key parts involved in running queries.

  • Plan Cache: Stores execution plans.
  • Buffer Pool: Stores data pages from disk in memory so SQL Server can access them quickly.
  • Execution Engine: The part that actually runs the query plan and processes the data.

Normal SQL query and stored procedures both use all these pieces, but stored procedures often make better use of caching.

Examples
Raw SQL Query.
SELECT * FROM Orders WHERE CustomerID = 'PETER';

Equivalent Stored Procedure.
CREATE PROCEDURE sp_GetOrdersByCustomer
    @CustomerID NVARCHAR(5)
AS
BEGIN
    SELECT * FROM Orders WHERE CustomerID = @CustomerID;
END;

Running this many times with different values.

  • The Normal SQL query version creates multiple plans.
  • The stored procedure reuses the same plan with different values.

Side-by-Side Execution Flow

Note: Unless there are schema updates or recompilation triggers, stored procedures bypass parsing, name resolution, and optimization after the initial execution.

Key Differences

Step Raw SQL Query Stored Procedure
Parsing Every time Once
Algebrizing (name resolution) Every time Once
Optimization Every time Once (plan is cached)
Plan Cache Usage Optional (based on parameterization) Always cached
Security Less secure (SQL injection risk) More secure
Performance Slower for repeated queries Faster due to plan reuse

Conclusion

Scenario Best Approach
Dynamic filters or one-off queries Raw SQL Query
Repeated logic, reporting, automation Stored Procedure
Need security, performance, versioning Stored Procedure

Normal SQL queries and stored procedures both help us get data from the database, but they work differently behind the scenes. While both stored procedures and standard SQL queries assist us in retrieving data from the database, their inner workings differ. Every time a standard query is executed, it undergoes parsing, verification, and planning. This is done only once using a stored process, which also saves the plan for later usage, making it faster. When you need to execute the same logic repeatedly or want greater control and security, stored procedures are preferable. Writing better, faster, and safer SQL code is made possible by understanding how both are handled.

HostForLIFE.eu SQL Server 2022 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.