# Jdbc Configuration Recommendation

__*JDBC configurations recommendation*__

+ `useSSL=true|false`: For connectors 8.0.12 and earlier
+ `sslMode=<mode_name>`: For connectors 8.0.13 and later

```12
JDBC:mysql://{TiDBIP}:{TiDBPort}/{DBName}?\
characterEncoding=utf8&\
~!@cachePrepStmts=true@!~&\
~!@useServerPrepStmts=true@!~&\
~!@prepStmtCacheSqlLimit=10000000000@!~&\
~!@useConfigs=maxPerformance@!~&\
~!@rewriteBatchedStatements=true@!~&\
~!@defaultfetchsize=-214783648@!~
```

------------------------------------------------------------

For security, it is recommended to enable TLS. For more information please reference: https://docs.pingcap.com/tidb/v6.0/enable-tls-between-clients-and-servers

1. characterEncoding:
    Characters in Java use Unicode encoding, each character occupies two bytes and 16 binary bits. When storing data in ByteBuffer, the encoding of the character needs to be considered, and when reading from it, the encoding and decoding of the character also needs to be considered.

2. useServerPrepStmts:
    SQL injection can be prevented. For performance reasons, cache for PreparedStatements should be enabled on the database connection pool. If you are not using a connection pool, or if the connection pool you are using does not support PSCache, you can also set cachePrepstMTS=true on the JDBC connection.

3. useConfigs：useConfigs=maxPerformance: 
    This setting is equal to:
```
cachePrepStmts=true
cacheCallableStmts=true
cacheServerConfiguration=true
useLocalSessionState=true
elideSetAutoCommits=true
alwaysSendSetIsolation=false
enableQueryTimeouts=false
```

4. rewriteBatchedStatements:
    By default, the MySQL JDBC driver ignores the ExecuteBatch () statement, splits a set of SQL statement that we expect to execute in batch and send them to the MySQL database one by one, directly causing low performance. Only by setting the RewriteBatchedStatements flag to true will the driver help you execute SQL in batch (jdbc:mysql: //ip:port/db? RewriteBatchedStatements=true).

5. defaultfetchsize:
    The setting of fetchsize is related to the specific business system, and there is not a single best value that can be used by each application. In general OLTP systems, fetchsize uses the default value of jdbc. I looked at most articles on the web, test fetchsize under a specific condition and came up with a value that everyone then used to set their own application system. In general, this is just a waste of some resources, but in some cases, such as data source splitting, reads and writes separation architectures, when the fetchsize is set too large, it may lead to a sharp drop in performance, and even lead to a terrible JVM out of memory on the application. It is recommended to do a DUMP of the JVM memory before setting this value so that you can have a clear understanding of the memory usage.