Is it correct that prepared statements should be considered a less effective means of improving db performance than stored procedures because stored procs persist across sessions while prepared statements do not? In other words, prepared statements get re-compiled and cached per session?
I realize that there's a few questions on this site about this but none seem to address this specific question. No need to comment on the comparison other than in regards to this specific question.
In a lot of cases, the performance difference is negligible.
The real performance savings using a stored procedure comes from reducing the number of round trips to the database, when the stored procedure is performing multiple SQL statements.
If a stored procedure is wrapping a single SQL statement, and it's being called from the application in place of a single SQL statement, then it's unlikely there is any performance benefit with MySQL. (There may actually be a little more work for MySQL to do calling the stored procedure.)
Where we usually get a performance boost with a stored procedure is reducing the number of statements executed by the client; that is, eliminating some of the statement "execute" calls.
Related
My situation:
MySQL 5.5, but possible to migrate to 5.7
Legacy app is executing single MySQL query to get some data (1-10 rows, 20 columns)
Query can be modified via application configuration
Query is very complex SELECT with multiple JOINS and conditions, it's about 20KB of code
Query is well profiled, index usage fine-tuned, I spent much time on this and se no room for improvement without splitting to smaller queries
With traditional app I would split this large query to several smaller and use caching to avoid many JOINS, but my legacy app does not allow to do that. I can use only one query to return results
My plan to improve performance is:
Reduce parsing time. Parsing 20KB of SQL on every request, while only parameters values are changed seems ineffective
I'd like to turn this query into prepared statement and only fill placeholders with data
Query will be parsed once and executed multiple times, should be much faster
Problems/questions:
First of all: does above solution make sense?
MySQL prepared statements seem to be session related. I can't use that since I cannot execute any additional code ("init code") to create statements for each session
Other solution I see is to use prepared statement generated inside procedure or function. But examples I saw rely on dynamically generating queries using CONCAT() and making prepared statement executed locally inside of procedure. It seems that this kind of statements will be prepared every procedure call, so it will not save any processing time
Is there any way to declare server-wide and not session related prepared statement in MySQL? So they will survive application restart and server restart?
If not, is it possible to cache prepared statements declared in functions/procedures?
I think the following will achieve your goal...
Put the monster in a Stored Routine.
Arrange to always execute that Stored Routine from the same connection. (This may involve restructuring your client and/or inserting a "web service" in the middle.)
The logic here is that Stored Routines are compiled once per connection. I don't know whether that includes caching the "prepare". Nor do I know whether you should leave the query naked, or artificially prepare & execute.
Suggest you try some timings, plus try some profiling. The latter may give you clues into what I am uncertain about.
I will get some text from another question here:
The PreparedStatement is a slightly more powerful version of a Statement, and should always be at least as quick and easy to handle as a Statement.
The Prepared Statement may be parametrized
Most relational databases handles a JDBC / SQL query in four steps:
Parse the incoming SQL query
Compile the SQL query
Plan/optimize the data acquisition path
Execute the optimized query / acquire and return data
A Statement will always proceed through the four steps above for each SQL query sent to the database. A Prepared Statement pre-executes steps (1) - (3) in the execution process above. Thus, when creating a Prepared Statement some pre-optimization is performed immediately. The effect is to lessen the load on the database engine at execution time.
Now here is my question:
If I use hundreds or thousands of Statement, will it be cause performance problems in database? (I don't mean that they will perform slower because of more jobs to do every time). Will all those statements be cached in database or they will be lost in space as soon as they are executed?
Since there is no restictions on using prepared statements, you should work carefully with them.
As you said you need hundreds of prepaired, think twice may be you are using it wrong.
The pattern it should be used is having an application that doing a haevy inserts/updates/select hundred or thousand times a second which only differs in variables. So in real world it would be like, connecting, creating session, sending statement, and sending bunch of variables to that statement.
But if your plan is to create prepared on each single operations, it's just better to use common queries.
On your questions:
Hundreds of statements will not kill mysql or drive you to performance degradation
The prepared are stored in memory while client session is up and running. As soon as you close session the prepared die.
To be sure you need it:
Your app able to execute statements fast so you get speed value of using them
Your query will not have a variable number of arguments, otherwise you can kill you app by creating objects and storing in memory on every statement
It is obvious that executing database query in loops has performance issues. but if the query is used as prepared statement, does it make any difference?
What is preferable joining together the tables and get the results or using prepared statement in loop?
Using join would almost always be preferred instead of looping over a result set to get additional results.
Relational Database Management Systems are built for combining related results, and does so very efficiently... additionally, this will you save many round trips to the database, which can become costly if used excessively - regardless of if you're using prepared statements or not.
The overhead to the prepared statements is probably not going to be the escaping of the inputs, it's going to be the connection to the database, or reconnection, or act of sending of the finalized sql statement. That interface between your code and the relational database is likely to be the slow point of the process more than anything else.
However, for my part, I would generally go for whatever is simplest and most able to be maintained from the start, and only worry about performance if the performance actually shows itself to be slow. Write the data-grabbing functionality in a separate function or method so that the implementation can change if the performance proves to need optimization, though.
At that point you can then start optimizing your sql, and use joins or unions as alternatives to multiple prepared statements.
I have tried a query on mysql, the query had called other functions.
Then I added the very same query in a stored procedure and then executed the procedure on mysql.
The execution time of the normal query was less by 1 sec than the procedure.
Weren't it supposed to be the opposite because procedures get cached.
Please explain to me if I'm missing something here. I appreciate your knowledge sharing a lot.
Regards
Stored Procedure is parsed and compiled only once when it's first created in the database while a text query needs to be parsed and compiled every time it's executed. and this is the difference and it's tiny for a limited number of calls.
If you are trying to compare just for a single query, then query is best way to opt, but for large queries, you should use stroed procedures.
I don't know for mysql, but for other database engines like Oracle, the queries may be cached and linked to the connection once compiled. Even the data may be cached in fact.
Did you try to launch the query and the stored procedure several times each? It is mandatory to have a correct estimation of the performance.
Is there ever a performance benefit to stored procedure that can't be achieved without them?
Very large queries can be optimized with a stored procedure, but the difference is usually small.
A large query from an application needs to be transmitted over the wire, then parsed by the SQL server.
Using a stored procedure, the amount of data transmitted can be reduced, and parsing does not need to be performed each time the procedure is called.
When you have to perform more than one query inside the stored procedure.
Assuming two queries - there's the trip back & forth that you can't recoup (assuming the database & application code aren't on the same box -- common in medium to large scale applications). Plus the concern of managing the transaction...
Not so much a performance concern, but the fact that someone can submit any SQL, besides the security around parameterized queries, is a huge security concern.
If you are talking solely about execution time performance (not maintainability) then Stored Procedures generally outperform non-parametrized queries because their execution plan is cached automatically by the SQL server.
Note that parametrized queries as opposed to non-parametrized queries may also be cached by the SQL server but generally speaking it is more likely to get execution plan caching when using stored procedures since that implies that the same query will be used to perform the same task regardless of where you're calling it in an application.