In one search for Top SQL, it was found that the DB executed a large number of select @@session.tx_read_only , and almost every DML statement had such a SQL before. But the application layer does not do special processing, so what does this SQL statement do? who executed it?
The role of this sql is mainly to determine whether the transaction is a read-only transaction. MySQL itself will optimize read-only transactions, which only appeared after MySQL 5.6.5 . http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_tx_read_only
Locate the driver package of MySQL
ConnectionImpl.java :
It can be seen that in the if condition, the version of MySQL is judged, and there is also a condition such as !getUseLocalSessionState(), which corresponds to the JDBC parameter useLocalSessionState . When this value is false, it will issue select @@session.tx_read_only; sql.
By default, our connection string information does not include the setting of the useLocalSessionState parameter, which defaults to false.
The role of this value is whether the driver uses the internal values of autocommit, read_only and transaction isolation (local values on the jdbc side).
If it is set to false, you need to send a statement to the remote request in the scenario of judging these three parameters. For example, before updating the statement, you
need to send the statement select @@session.tx_read_only to confirm whether the session is read-only.
If set to true, you only need to take the local value. This can explain why there are many instances of select @@session.tx_read_only statements.
In general, the driver can ensure that the local value is consistent with the remote server value. When the application calls the three interfaces of setAutoCommit, setTransactionIsolation and setReadOnly to set parameter values, it will synchronize with the remote server.
in particular,
When useLocalSessionState is true, if the value is inconsistent with the local value, it will be sent to remote update;
when useLocalSessionState is false, regardless of whether the set value is consistent with the local value, it will be sent to remote update every time. This can explain why some instances have more set autocommit statements.
However, if the user does not set the parameters through the JDBC interface (such as setAutoCommit), but executes the statement 'set autocommit=xxx', then there will be a situation where the local value is inconsistent with the remote one, which may lead to the business logic after modifying the parameter useLocalSessionState. change.
SQL statement for related settings:
set autocommit=0 /*Set the session autocommit mode*/ Corresponding JDBC interface: setAutoCommit(false)
set tx_isolation='read-committed' /*Set the isolation level of the transaction*/ Corresponding JDBC interface: setTransactionIsolation('read-committed')
set tx_read_only=0; /*Set read-only transaction*/ Corresponding JDBC interface: setReadOnly(false)
Setting the default value of useLocalSessionState to true may lead to changes in the meaning of business logic. The trigger condition is that the user directly sets the auto-commit parameter, the isolation level parameter or the read-only transaction parameter through the SQL statement.