First look at a jdbc url address:
`url: jdbc:mysql://127.0.0.1:3306/test?useAffectedRows=true&autoReconnect=true&useUnicode=true&characterEncoding=utf-8&allowMultiQueries=true&zeroDateTimeBehavior=convertToNull&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai`
Next, we will gradually analyze the configuration inside and the problems solved.
1.useAffectedRows=true
When we perform an update operation, we often make some logical judgments based on the update results. For example, if the return value is greater than 1, it means the update is successful, and if it is 0, it means the update failed.
However, when using the Mysql driver to connect to the database and perform update operations, the return value may not be as expected.
For example, SQL1: update task_info SET task_status=2 where id=?
No matter how many times this SQL is executed, the update return value may be 1. The reason lies in MySQL's connection URL.
Modify mysqlURL and add the parameter useAffectedRows=true .
jdbc:mysql://127.0.0.1:3306/test?characterEncoding=utf-8&useAffectedRows=true
The function of useAffectedRows is whether to use the number of affected rows instead of the number of found rows to return data. The default is false. After specifying this value, the number of updated rows will be returned during update. The update operation according to SQL1 will also return normal values, that is, 1 will be returned for the first time and 0 for the second time.
2.autoReconnect=true
Set autoReconnect=true for database connection timeout, and adjust the default number of retries
Should the driver attempt to re-establish the connection? If enabled, the driver will throw exceptions for queries issued on stale or dead connections that are part of the current transaction, but not before the next query issued on the connection in a new transaction. Try to reconnect. The use of this feature is not recommended as it has side effects with session state and data consistency when the application does not handle exceptions properly, and is only designed to be used when you are unable to configure your application to handle exceptions resulting in dead and stale connections properly. Also, as a last option, look into setting the MySQL server variable "wait_timeout" to a higher value than the default 8 hours.
3.useUnicode=true&characterEncoding=utf-8
The mysql database uses gbk encoding, and the project's mysql database requires utf-8 encoding, so add useUnicode=true&characterEncoding=utf-8" after the url, indicating that UTF-8 format will be used when storing data in the database. Decode the data into bytecode, and then reuse the decoded bytecode to store it in the database using GBK encoding. When fetching data from the database, the data will be decoded into bytecode in GBK format, and then the bytecode will be decoded into bytecode. The code re-encodes the data in UTF-8 format and returns it to the client.
4.allowMultiQueries=true
When MySQL connects to the database, add the statement: " allowMultiQueries=true ". The functions:
1. You can carry a semicolon after the sql statement to achieve multi-statement execution.
2. You can execute batch processing and issue multiple SQL statements at the same time.
5.zeroDateTimeBehavior=convertToNull
When querying the Mysql database, an exception sometimes occurs:
Value ‘0000-00-00 00:00:00’ can not be represented as java.sql.Timestamp. Stacktrace follows:
java.sql.SQLException: Value ‘0000-00-00 00:00:00’ can not be represented as java.sql.Timestamp
Datetimes with all-zero components (0000-00-00 ...): These values cannot be represented reliably in Java. Connector/J 3.0.x always converted them to NULL when being read from a ResultSet.
The key is that in Mysql 0000-00-00 00:00:00 may be valid; in Java, such conversion is invalid.
Therefore, the Mysql JDBC driver will throw a java.sql.SQLException because Java does not recognize the date format 0000-00-00 00:00:00.
6.useSSL=false
SSL an encryption protocol
It was found that versions before MySQL 5.7 were less secure and there was a test library that any user could connect to, so the official increased privacy protection in version 5.7. And the default value of useSSL = true is adopted to prevent arbitrary modification of the database. In version 8.0, SSL is still retained, and the default value is true, so just put "?useSSL= false" after the url table name.
7.allowPublicKeyRetrieval=true
If the user uses sha256_password authentication, the password must be protected by the TLS protocol during transmission , but if the RSA public key is not available, the public key provided by the server can be used; the server's RSA public key can be specified through ServerRSAPublicKeyFile
in the connection , or AllowPublicKeyRetrieval=True parameter to allow the client to obtain the public key from the server; however, it should be noted that AllowPublicKeyRetrieval=True may cause a malicious agent to obtain the plaintext password through a man-in-the-middle attack ( MITM ), so it is turned off by default and must be explicitly turned on.
8.serverTimezone=Asia/Shanghai
Improper time zone settings may cause various problems. Below we list several common problems and solutions:
8.1 MySQL internal time is not Beijing time
If you encounter this kind of problem, first check whether the system time and time zone are correct, and then look at the time_zone of MySQL. It is recommended to change the time_zone to '+8:00'.
8.2 There is a difference of 8 hours between the time accessed by the Java program and the time in the database.
The most likely cause of this problem is that the program time zone is inconsistent with the database time zone. We can check the time zones on both sides. If we want to use Beijing time uniformly, we can add serverTimezone=Asia/Shanghai in the jdbc connection string, and MySQL can also change time_zone to '+8:00'.
8.3 The difference between program time and database time is 13 hours or 14 hours
If the difference of 8 hours is not surprising enough, the difference of 13 hours may leave many people scratching their heads. The reason for this problem is that JDBC and MySQL have inconsistent negotiation of the "CST" time zone. Because the CST time zone is a very confusing time zone, it has four meanings:
Central Standard Time (USA) UTC-05:00 or UTC-06:00Central
Standard Time (Australia) UTC+09:30China
Standard Time UTC+08:00Cuba
Standard Time UTC -04:00
In MySQL, if time_zone is the default SYSTEM value, the time zone will be inherited as the system time zone CST, which is considered UTC+08:00 internally by MySQL. And jdbc will regard CST as the Central Time of the United States, which will result in a difference of 13 hours. If it is winter time, there will be a difference of 14 hours.
The method to solve this problem is also very simple. We can clearly specify the time zone of the MySQL database without using the misleading CST. We can change time_zone to '+8:00', and we can also add serverTimezone=Asia/Shanghai to the jdbc connection string. .