When you use a prepared statement (for example, a precompiled statement), as soon as the DB receives this statement, it compiles it and caches it so that it can use the last compiled statement to invoke the same statement in sequence. Therefore, it becomes precompiled for consecutive calls.
Usually you use a prepared statement with binding variables, where you specify variables at run time. Now, what happens for the sequential execution of prepared statements, you can specify variables that are different from previous calls. From the point of view of the database, it does not need to make an instruction every time, just insert the binding variables during rum. So it gets faster.
Other benefits of prepared statements are: -
1) SQL injection attack protection
2) Faster for consecutive calls of the same operators
How it works: -
Precompilation is performed by the database. Some simpler databases do not precompile statements at all. Others may pre-compose it in a call to prepareStatement, and yet others can do this when the call is first called in an instruction, taking into account the parameter values ββwhen compiling (creating a plan) the instruction.
Databases that precompile statements usually cache them, so in all likelihood ps1 will not be compiled again. Some JDBC drivers (such as Oracle) even cached prepared statements, so they didnβt actually close it when ps.close () was called.
Databases are usually cached by statements until something pushes them out of the cache.
See wiki for more details.
M sach
source share