If 'cacheCallableStmts' is enabled, how many callable statements should be cached?
Default Value 100 Since Version 3.1.2
The number of queries to cache ResultSetMetadata for if cacheResultSetMetaData is set to 'true' (default 50)
Default Value 50 Since Version 3.1.1
Should the driver refer to the internal values of autocommit and transaction isolation that are set by Connection.setAutoCommit() and Connection.setTransactionIsolation() and transaction state as maintained by the protocol, rather than querying the database or blindly sending commands to the database for commit() or rollback() method calls?
Default Value false Since Version 3.1.7
Should the driver use the in-transaction state provided by the MySQL protocol to determine if a commit() or rollback() should actually be sent to the database?
Default Value false Since Version 5.1.7
If prepared statement caching is enabled, how many prepared statements should be cached?
Default Value 25 Since Version 3.0.10
If prepared statement caching is enabled, what's the largest SQL the driver will cache the parsing for?
Default Value 256 Since Version 3.0.10
Name of a class implementing com.mysql.cj.CacheAdapterFactory, which will be used to create caches for the parsed representation of client-side prepared statements.
Default Value com.mysql.cj.PerConnectionLRUFactory Since Version 5.1.1
Name of a class implementing com.mysql.cj.CacheAdapterFactory<String, Map<String, String>>, which will be used to create caches for MySQL server configuration values
Default Value com.mysql.cj.util.PerVmServerConfigCacheFactory Since Version 5.1.1
Should the driver always communicate with the database when Connection.setTransactionIsolation() is called? If set to false, the driver will only communicate with the database when the requested transaction isolation is different than the whichever is newer, the last value that was set via Connection.setTransactionIsolation(), or the value that was read from the server when the connection was established. Note that useLocalSessionState=true will force the same behavior as alwaysSendSetIsolation=false, regardless of how alwaysSendSetIsolation is set.
Default Value true Since Version 3.1.7
Should the driver maintain various internal timers to enable idle time calculations as well as more verbose error messages when the connection to the server fails? Setting this property to false removes at least two calls to System.getCurrentTimeMillis() per query.
Default Value true Since Version 3.1.9
Should the driver use cursor-based fetching to retrieve rows? If set to "true" and "defaultFetchSize" > 0 (or setFetchSize() > 0 is called on a statement) then the cursor-based result set will be used. Please note that "useServerPrepStmts" is automatically set to "true" in this case because cursor functionality is available only for server-side prepared statements.
Default Value false Since Version 5.0.0
Should the driver cache the parsing stage of CallableStatements
Default Value false Since Version 3.1.2
Should the driver cache the parsing stage of PreparedStatements of client-side prepared statements, the "check" for suitability of server-side prepared and server-side prepared statements themselves?
Default Value false Since Version 3.0.10
Should the driver cache ResultSetMetaData for Statements and PreparedStatements? (Req. JDK-1.4+, true/false, default 'false')
Default Value false Since Version 3.1.1
Should the driver cache the results of 'SHOW VARIABLES' and 'SHOW COLLATION' on a per-URL basis?
Default Value false Since Version 3.1.5
The driver will call setFetchSize(n) with this value on all newly-created Statements
Default Value 0 Since Version 3.1.9
Stops checking if every INSERT statement contains the "ON DUPLICATE KEY UPDATE" clause. As a side effect, obtaining the statement's generated keys information will return a list where normally it wouldn't. Also be aware that, in this case, the list of generated keys returned may not be accurate. The effect of this property is canceled if set simultaneously with 'rewriteBatchedStatements=true'.
Default Value false Since Version 5.1.32
If using MySQL-4.1 or newer, should the driver only issue 'set autocommit=n' queries when the server's state doesn't match the requested state by Connection.setAutoCommit(boolean)?
Default Value false Since Version 3.1.3
Sets the default escape processing behavior for Statement objects. The method Statement.setEscapeProcessing() can be used to specify the escape processing behavior for an individual Statement object. Default escape processing behavior in prepared statements must be defined with the property 'processEscapeCodesForPrepStmts'.
Default Value true Since Version 6.0.1
When enabled, query timeouts set via Statement.setQueryTimeout() use a shared java.util.Timer instance for scheduling. Even if the timeout doesn't expire before the query is processed, there will be memory used by the TimerTask for the given timeout which won't be reclaimed until the time the timeout would have expired if it hadn't been cancelled by the driver. High-load environments might want to consider disabling this functionality.
Default Value true Since Version 5.0.6
What size result set row should the JDBC driver consider "large", and thus use a more memory-efficient way of representing the row internally?
Default Value 2048 Since Version 5.1.1
Should the driver issue appropriate statements to implicitly set the transaction access mode on server side when Connection.setReadOnly() is called? Setting this property to 'true' enables InnoDB read-only potential optimizations but also requires an extra roundtrip to set the right transaction state. Even if this property is set to 'false', the driver will do its best effort to prevent the execution of database-state-changing queries. Requires minimum of MySQL 5.6.
Default Value true Since Version 5.1.35
Should the driver use multiqueries (regardless of the setting of "allowMultiQueries") as well as rewriting of prepared statements for INSERT into multi-value inserts when executeBatch() is called? Notice that this has the potential for SQL injection if using plain java.sql.Statements and your code doesn't sanitize input correctly. Notice that for prepared statements, server-side prepared statements can not currently take advantage of this rewrite option, and that if you don't specify stream lengths when using PreparedStatement.set*Stream(), the driver won't be able to determine the optimum number of parameters per batch and you might receive an error from the driver that the resultant packet is too large. Statement.getGeneratedKeys() for these rewritten statements only works when the entire batch includes INSERT statements. Please be aware using rewriteBatchedStatements=true with INSERT .. ON DUPLICATE KEY UPDATE that for rewritten statement server returns only one value as sum of all affected (or found) rows in batch and it isn't possible to map it correctly to initial statements; in this case driver returns 0 as a result of each batch statement if total count was 0, and the Statement.SUCCESS_NO_INFO as a result of each batch statement if total count was > 0.
Default Value false Since Version 3.1.13
Use newer, optimized non-blocking, buffered input stream when reading from the server?
Default Value true Since Version 3.1.5