An inefficient SQL statement is enough to ruin the entire application.
Statement is the parent interface of PreparedStatement and does not pre-compile, reducing the overhead of precompiling. A single run of PreparedStatement is slower than statement.
PreparedStatement can implement all functions of statement, but it is called precompiled instruction because it can be given a certain format of SQL string when creating an object of it, and then use its Setxxx method to assign a value to the specified SQL statement in a blank way , with such an attribute, it is convenient and more efficient to execute a fixed-format string multiple times. Unlike statement, it is necessary to compile the string before executing SQL.
PreparedStatement requires server-side support to improve efficiency. For example, there is a significant effect on Oracle, and MySQL clearly illustrates that PreparedStatement is not supported.
Oracle will compile all the SQL statements, called "Execution plan", placed in a specific Oracle internal cache, each encounter the same SQL, will call the cache, if not precompiled, each time with statement, then every time to compile, There are many duplicate "execution plans" in the buffer that affect the performance of the database. Another point is that when using setobject (), be sure to use the method with Targetsqltype parameters to improve efficiency.
The SQL injection attack exploits the design vulnerability, runs SQL statements on the target server, and does not validate the data entered by the user when dynamically generating SQL statements, which is the main reason for the successful SQL injection attack.
For JDBC, the SQL injection attack is valid only for statement and is not valid for PreparedStatement because PreparedStatement does not allow the logical structure of the query to be changed at insert time.
Bypass validation, but this method is only valid for statement, and is not valid for PreparedStatement.
If there is an SQL statement: "SELECT * from table where user name = ' User name '"
The statement SQL statement reads: "SELECT * from table where user name = '" + Variable Value + "'"
The PreparedStatement SQL statement reads: "SELECT * from table where user name =?" then the corresponding assignment
So we'll find the input "AA ' or ' 1 ' = ' 1"
Statement is to concatenate this and SQL statement strings together to execute
PreparedStatement is that "AA ' or ' 1 ' = ' 1" is assigned as a string, as the corresponding value of the "username" field, so SQL injection does not have to be discussed.
The implementation mechanism is different, injected only to the SQL statement Preparation (compilation) process has a destructive effect, and PreparedStatement is ready, the execution phase is just the input string as data processing, no longer need to parse the SQL statement, preparation, therefore also avoids the SQL injection problem.
Oracle Architecture------Oracle uses PreparedStatement to prevent SQL injection---Reprint