---restore content starts---
1. PreparedStatement interface Inherits Statement, preparedstatement instance contains compiled SQL statement, so it executes faster than Statement object.
2. As a subclass of Statement, PreparedStatement inherits all the functions of Statement. Three different methods
Execute, ExecuteQuery, and executeupdate have been changed so that they no longer require parametersAlthough using PreparedStatement instead of statement will make the code a few more lines, this code can be used in terms of readability and maintainability. It is much higher than the code that directly uses statement:
Stmt.executeupdate ("INSERT into Tb_name (COL1,COL2,COL2,COL4) VALUES ('" +var1+ "', '" +var2+ "'," +var3+ ", '" +var4+ "')") ;//stmt is a statement object instance
perstmt = Con.preparestatement ("INSERT into Tb_name (COL1,COL2,COL2,COL4) VALUES (?,?,?,?)");
Perstmt.setstring (1,VAR1);
Perstmt.setstring (2,VAR2);
Perstmt.setstring (3,VAR3);
Perstmt.setstring (4,VAR4);
Perstmt.executeupdate (); Prestmt is an PreparedStatement object instance
Statements are cached by the compiler-compiled execution code of the DB, so the next call will not need to compile as long as it is the same precompiled statement, as long as the parameters are passed directly into the compiled statement execution code (equivalent to a culvert number) will be executed. This is not to say that only a precompiled statement that executes multiple times in a connection is cached, but for the entire DB, as long as the precompiled statement syntax matches the cache. At any time, it is possible to execute directly without having to compile again. And in statement's statement, Even with the same operation, the chances of matching the entire statement are almost impossible to match because of the different data for each operation. For example:
Insert into Tb_name (col1,col2) VALUES (' 11 ', ' 22 ');
Insert into Tb_name (col1,col2) VALUES (' 11 ', ' 23 ');
Even though the same operation is not the same as the data content, the entire statement itself does not match, there is no meaning of the cached statement. The fact is that there is no database that executes code caches after the normal statement is compiled.
Of course not. So the precompiled statements are bound to be cached, and the database itself uses a strategy, such as frequency, to determine when the pre-compiled results are no longer cached. To save more space to store new precompiled statements. The most important point is that it greatly improves security.
Even so far, some people don't even know the basic semantics of SQL syntax.
String sql = "SELECT * from Tb_name where name= '" +varname+ "' and passwd= '" +varpasswd+ "'";
If we pass [' or ' 1 ' = ' 1] in as varpasswd. User name feel free to see what will become?
SELECT * from tb_name = ' random ' and passwd = ' or ' 1 ' = ' 1 ';
Because ' 1 ' = ' 1 ' is sure to be true, so you can pass any validation. What's more:
Put [';d rop table tb_name;] Incoming in as VARPASSWD:
SELECT * from tb_name = ' random ' and passwd = ';d rop table tb_name; some databases are not going to make you successful, but there are many databases that can make these statements executable.
And if you use precompiled statements. Anything you pass in will not have any matching relationship with the original statement. As long as you use precompiled statements all the time, you don't have to worry about the incoming data. If you use ordinary statement, you may want to make a decision on the drop,;
---restore content ends---
Why use PreparedStatement in Java instead of statement
