# Using The Prepared Statement Api __*useServerPrepStmts*__ + `OLTP` friendly + `useServerPrepStmts` ```12 jdbc:mysql://:/?~!@useServerPrepStmts=true@!~ ``` ------------------------------------------------------------ For OLTP scenario, the SQL statement sent by the program to the database are exhaustible after removing flag changes. Therefore, it is recommended to use Prepared Statements (Prepared Statements) instead of plain text execution and reuse the prepared statement for direct execution, thereby avoiding the overhead of TiDB repeated parse and generating SQL execution plans. 1. Performance improvement Like select * from user where id = 1, this kind of ordinary statement is called Immediate Statement, and it must go through a complete SQL execution process when executed. Shaped like select * from user where id =? , Use placeholders instead of the values of column in a statement. This kind of statement is called Prepared Statement. When executed, it must first be precompiled, and then each execution omits the process of parsing optimization. Prepared statement are applicable scenario: an SQL statement needs to be executed multiple times and only the value of the column may change (for example, the value of the where clause of query is different, the value of the set clause of update is different, and the values value of insert is different) 2. safety Using preparedstatement in JDBC is necessary and can effectively prevent sql injections. Currently, most upper level framework call the Prepare API for SQL execution. If you use the JDBC API to develop directly, pay attention to choosing to use the Prepare API. In addition, it is important to note that the MySQL Connector/J implement only prepares statement for the client by default. It is sent to the server as text after client substitution, so in addition to using the Prepare API, you need to configure useServerPrepstMts = true in the JDBC connection flag in order to preprocess statement on the TiDB server side.