Primero mire una dirección URL de jdbc:
`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`
A continuación iremos analizando poco a poco la configuración interna y los problemas solucionados.
1.useAffectedRows=verdadero
Cuando realizamos una operación de actualización, a menudo hacemos algunos juicios lógicos basados en los resultados de la actualización. Por ejemplo, si el valor de retorno es mayor que 1, significa que la actualización se realizó correctamente, y si es 0, significa que la actualización falló.
Sin embargo, cuando se utiliza el controlador Mysql para conectarse a la base de datos y realizar operaciones de actualización, es posible que el valor de retorno no sea el esperado.
Por ejemplo, SQL1: actualizar task_info SET task_status=2 donde id=?
No importa cuántas veces se ejecute este SQL, el valor de retorno de la actualización puede ser 1. La razón radica en la URL de conexión de MySQL.
Modifique mysqlURL y agregue el parámetro useAffectedRows=true .
jdbc:mysql://127.0.0.1:3306/test?characterEncoding=utf-8&useAffectedRows=true
La función de useAffectedRows es si se debe utilizar el número de filas afectadas en lugar del número de filas encontradas para devolver datos, el valor predeterminado es falso. Después de especificar este valor, se devolverá el número de filas actualizadas durante la actualización. La operación de actualización según SQL1 también devolverá valores normales, es decir, se devolverá 1 la primera vez y 0 la segunda vez.
2.autoReconnect=verdadero
Establezca autoReconnect=true para el tiempo de espera de conexión de la base de datos y ajuste el número predeterminado de reintentos
¿Debería el controlador intentar restablecer la conexión? Si está habilitado, el controlador generará excepciones para consultas emitidas en conexiones obsoletas o inactivas que forman parte de la transacción actual, pero no antes de la siguiente consulta emitida en la conexión en una nueva transacción. Intenta volver a conectarte. No se recomienda el uso de esta característica ya que tiene efectos secundarios con el estado de la sesión y la coherencia de los datos cuando la aplicación no maneja las excepciones correctamente, y solo está diseñada para usarse cuando no puede configurar su aplicación para manejar excepciones que resultan en inactividad y conexiones obsoletas correctamente. Además, como última opción, considere configurar la variable del servidor MySQL "wait_timeout" en un valor superior al valor predeterminado de 8 horas.
3.useUnicode=true&characterEncoding=utf-8
La base de datos mysql usa codificación gbk, y la base de datos mysql del proyecto requiere codificación utf-8, por lo tanto, agregue useUnicode=true&characterEncoding=utf-8" después de la URL, lo que indica que se usará el formato UTF-8 al almacenar datos en la base de datos. Decodifica el datos en código de bytes, y luego reutilizar el código de bytes decodificado para almacenarlo en la base de datos usando codificación GBK. Al recuperar datos de la base de datos, los datos se decodificarán en código de bytes en formato GBK, y luego el código de bytes se decodificará en código de bytes. El código vuelve a codificar los datos en formato UTF-8 y los devuelve al cliente.
4.allowMultiQueries=verdadero
Cuando MySQL se conecta a la base de datos, agregue la declaración: " allowMultiQueries=true " Las funciones:
1. Puede llevar un punto y coma después de la declaración SQL para lograr la ejecución de múltiples declaraciones.
2. Puede ejecutar procesamiento por lotes y emitir múltiples declaraciones SQL al mismo tiempo.
5.zeroDateTimeBehavior = convertir a nulo
Al consultar la base de datos Mysql, a veces ocurre una excepción:
El valor '0000-00-00 00:00:00' no se puede representar como java.sql.Timestamp. Stacktrace sigue:
java.sql.SQLException: el valor '0000-00-00 00:00:00' no se puede representar como 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.
La clave es que en Mysql 0000-00-00 00:00:00 puede ser válido; en Java, dicha conversión no es válida.
Por lo tanto, el controlador JDBC de Mysql generará una excepción java.sql.SQLException porque Java no reconoce el formato de fecha 0000-00-00 00:00:00.
6.useSSL=falso
SSL un protocolo de cifrado
Se descubrió que las versiones anteriores a MySQL 5.7 eran menos seguras y había una biblioteca de prueba a la que cualquier usuario podía conectarse, por lo que el funcionario aumentó la protección de la privacidad en la versión 5.7. Y el valor predeterminado de useSSL = true se adopta para evitar modificaciones arbitrarias de la base de datos. En la versión 8.0, SSL aún se conserva y el valor predeterminado es verdadero, así que simplemente coloque "? useSSL = false" después del nombre de la tabla de URL.
7.allowPublicKeyRetrieval=verdadero
Si el usuario usa la autenticación sha256_password , la contraseña debe estar protegida por el protocolo TLS durante la transmisión , pero si la clave pública RSA no está disponible, se puede usar la clave pública proporcionada por el servidor; la clave pública RSA del servidor se puede especificar a través de ServerRSAPublicKeyFile
en la conexión , o el parámetro AllowPublicKeyRetrieval=True para permitir que el cliente obtenga la clave pública del servidor; sin embargo, debe tenerse en cuenta que AllowPublicKeyRetrieval=True puede causar que un agente malicioso obtenga la contraseña en texto plano a través de un hombre en el- ataque medio ( MITM ), por lo que está desactivado de forma predeterminada y debe activarse explícitamente.
8.serverTimezone=Asia/Shanghái
Una configuración incorrecta de la zona horaria puede causar varios problemas. A continuación enumeramos varios problemas y soluciones comunes:
8.1 La hora interna de MySQL no es la hora de Beijing
Si encuentra este tipo de problema, primero verifique si la hora y la zona horaria del sistema son correctas y luego mire la zona horaria de MySQL. Se recomienda cambiar la zona horaria a '+8:00'.
8.2 Existe una diferencia de 8 horas entre la hora a la que accede el programa Java y la hora en la base de datos.
La causa más probable de este problema es que la zona horaria del programa no coincide con la zona horaria de la base de datos. Podemos verificar las zonas horarias en ambos lados. Si queremos usar la hora de Beijing de manera uniforme, podemos agregar serverTimezone=Asia/Shanghai en la cadena de conexión jdbc, y MySQL también puede cambiar la zona horaria a '+8:00'.
8.3 La diferencia entre el tiempo del programa y el tiempo de la base de datos es de 13 horas o 14 horas
Si la diferencia de 8 horas no es lo suficientemente sorprendente, la diferencia de 13 horas puede dejar a muchas personas rascándose la cabeza. La razón de este problema es que JDBC y MySQL tienen una negociación inconsistente de la zona horaria "CST". Debido a que la zona horaria CST es una zona horaria muy confusa, tiene cuatro significados:
Hora estándar central (EE. UU.) UTC-05:00 o UTC-06:00
Hora estándar central (Australia) UTC+09:30
Hora estándar de China UTC+08:00
Hora estándar de Cuba UTC -04:00
En MySQL, si time_zone es el SISTEMA predeterminado valor, la zona horaria se heredará como la zona horaria del sistema CST, que MySQL considera UTC+08:00 internamente. Y jdbc considerará CST como la hora central de los Estados Unidos, lo que resultará en una diferencia de 13 horas, si es horario de invierno, habrá una diferencia de 14 horas.
El método para resolver este problema también es muy simple. Podemos especificar claramente la zona horaria de la base de datos MySQL sin usar el CST engañoso. Podemos cambiar time_zone a '+8:00', y también podemos agregar serverTimezone=Asia/Shanghai. a la cadena de conexión jdbc.