Does the prepared SQL statements in a stored procedure make the performance better?

Question

I know there have already been lots of question about stored procedure vs prepared SQL statements, but I want to find out something different - if the prepared statements inside a procedure contribute to the performance of this stored procedure, which means make it better.

I have this question because I was told following points when searching some introduction of these 2 skills.

• Stored procedure will store and compile your series of statements in db, which will reduce the overhead of transferring & compiling.
• Prepare statements will be compiled and cached in db for multiple
  access which lead to less overhead.

I am puzzled about these 'compile', 'store', and 'overhead' - a little bit abstract.

I use prepared statement to avoid re-parse if it will be called frequently. However should I use prepared statements (to cache & compile) inside a procedure? Since my procedure would have already been stored and compiled in DB, prepare something inside seems meaningless. (compile what was compiled?)

edit with sample code:

Create or Replace procedure MY_PROCEDURE
Begin
    //totally meaningless here?
    declare sqlStmt varchar(300);
    declare stmt statement;

    set sqlStmt='update MY_TABLE set NY_COLUMN=? where NY_COLUMN=?';
    prepare stmt from sqlStmt;
    execute stmt using 2,1
    execute stmt using 4,3
        ..............
END

Is the the above one better than below, since it only parse the statement once? Or same, because statements in procedure will have been pre-compiled.

Create or Replace procedure MY_PROCEDURE
Begin
    update MY_TABLE set NY_COLUMN=2 where NY_COLUMN=1;
    update MY_TABLE set NY_COLUMN=4 where NY_COLUMN=3;
        ..............
END

Answer 1

In DB2 actually the opposite may be true. Statements in an SQL routine are prepared when the routine is compiled. Dynamic SQL statements, as in your example, are prepared during the routine run time.

As a consequence, the preparation of dynamic statements will take into account the most current table and index statistics and other compilation environment settings, such as isolation level, while static statements will use the statistics that were in effect during the routine compilation or the latest bind.

If you want stable execution plans, use static SQL. If your statistics change frequently, you may want to use dynamic SQL (or make sure you rebind your routines' packages accordingly).

The same logic applies to Oracle PL/SQL routines, although the way to recompile static SQL differs -- you'll need to invalidate the corresponding routines.

Answer 2

When you first run a stored procedure the database engine parses the procedure and works out the optimal query plan to use when executing it - it then stores this query plan so that every time you run the procedure it doesn't have to recalculate it.

You can see this youself in Management Studio. If you CREATE or ALTER the stored procedure in question, then open a new query and use:

SET STATISTICS TIME ON

In that same query window run the stored procedure. In the messages tab of the result the first message will be something like:

SQL Server parse and compile time: 
CPU time = 1038 ms, elapsed time = 1058 ms.

This is the overhead, execute the query again and you will see that the parse and compile time is now 0.

When you prepare a statement in code you get to take advantage of the same benefit. If you query is 'SELECT * FROM table WHERE @var = '+$var, each time you run that query SQL Server has to parse it and calculate the optimal execution plan. If you use a prepared statement SELECT * FROM table WHERE ?, SQL Server will calculate the optimal execution plan the first time you run the prepared statement, and from then on it can reuse the execution plan as with a stored procedure. The same goes if the statement you are executing is 'EXEC dbo.myProc @var = '+$var, SQL Server would still have to parse this statement each time so a prepared statement should still be used.

You do not need to prepare statements that you write inside stored procedures because they are already compiled as shown above - they are prepared statements in themselves.

On thing you should be aware of when using stored procedure and prepared statements is parameter sniffing.

SQL Server calculates and stores the optimal execution plan for the first variables used, if you happen to execute the stored procedure with some unusual variable on the first run, the execution plan stored may be completely suboptimal for the sorts of variables you typically use.

If you find you can execute a stored procedure from Management Studio and it takes say 2 seconds to execute, but performing the same action in your application takes 20 seconds, it's probably as a result of parameter sniffing.