Compartir tecnología | MySQL: comprender las zonas horarias en un artículo;

¿Aún te preocupan las siguientes preguntas:

¿Qué zona horaria se debe establecer en la especificación de instalación de MySQL?

La hora leída por la aplicación JAVA es 14 horas diferente a la hora de Beijing. ¿Por qué? ¿Cómo solucionarlo?

Para una empresa que ha estado funcionando durante un período de tiempo, ¿el cambio de zona horaria de MySQL afectará los datos de tipo de hora almacenados?

¿Es posible que la zona horaria de los datos de tipo horario sea incorrecta al migrar datos?

...

Después de leer este artículo podrás resolver todas las dudas anteriores. Lo primero que aparece son los parámetros de inicio y las variables del sistema relacionadas con la zona horaria.

Si desea especificar la zona horaria cuando se inicia MySQL, debe usar el parámetro de inicio: default-time-zone, ejemplo:

Después del inicio, podemos ver las variables del sistema. que controlan la zona horaria, La variable time_zone controla la zona horaria, que se puede modificar mediante el comando set cuando MySQL se está ejecutando (nota: no se puede escribir en my.cnf):

Los valores disponibles ​​​​Los parámetros de inicio y las variables del sistema siguen el mismo formato:

La variable system_time_zone solo tiene un valor global y ningún valor de sesión, y no se puede modificar dinámicamente. Cuando se inicia MySQL, intentará hacerlo. determine automáticamente la zona horaria del servidor y utilícela para configurar la variable del sistema system_time_zone. El valor no cambiará a partir de entonces. Cuando time_zone='system', esta es la zona horaria utilizada en el ejemplo, time_zone es CST y CST es el Octavo Distrito Este en RedHat:

Para resumir, hay dos puntos:

1. El valor de retorno de las funciones del sistema NOW() y CURTIME() se ve afectado por la zona horaria de la sesión actual

No solo seleccione now(), sino que también inserte... valores (now()) y DEFAULT CURRENT_TIMESTAMP del campo Atributos también se ven afectados por esto:

2. Los datos almacenados en el campo de tipo de datos de marca de tiempo se ven afectados por la zona horaria

El tipo de datos de marca de tiempo almacenará la información de la zona horaria de la sesión actual y se leerá de acuerdo con la sesión actual. La zona horaria se convierte en el valor insertado por el tipo de datos de fecha y hora, lo cual no se ve afectado; por la zona horaria. También se puede entender que los datos almacenados no cambiarán, pero los datos del tipo de marca de tiempo se convertirán de acuerdo con la zona horaria al leer:

Todas las cosas obvias sobre las zonas horarias están arriba, mencionamos anteriormente. El problema que tienes es la experiencia en la oscuridad.

1. ¿Qué zona horaria se debe establecer en las especificaciones de instalación de MySQL?

Para negocios nacionales, escriba default-time-zone=' 08:00' ` en my.cnf y confirme la zona horaria correspondiente para otras regiones y desarrolladores.

¿Por qué no configurarlo en sistema? Usar la hora del sistema también parece ser una buena opción, que es menos problemática. Hay dos razones por las que no se recomienda:

2. La hora leída por la aplicación JAVA es 14 horas diferente de la hora de Beijing ¿Por qué? ¿Cómo solucionarlo?

Esto generalmente se debe a que el atributo de zona horaria no está configurado para la conexión en los parámetros JDBC (especificados con el parámetro serverTimezone) y la zona horaria global no está configurada en MySQL, por lo que MySQL usa la hora del sistema. zona por defecto, es decir, CST.

De esta manera, la zona horaria de la sesión de la conexión establecida entre la aplicación y MySQL es CST. Anteriormente mencionamos que CST es la zona horaria de las 08:00 en RedHat, pero en realidad puede representar 4 zonas horarias a la vez:

Se utiliza la hora estándar de EE. UU. JDBC al analizar CST, lo que genera un error de zona horaria. La solución es simple: primero, cumpla con las especificaciones mencionadas anteriormente y configure la zona horaria '08:00' mostrada por MySQL; segundo, configure la zona horaria del servidor correcta para JDBC;

3. Para una empresa que ha estado funcionando durante un período de tiempo, ¿el cambio de zona horaria de MySQL afectará los datos de tipo de hora almacenados?

Para nada, sólo afectará a la lectura del tipo de datos de marca de tiempo. Debo mencionar aquí, ¿por qué usar la marca de tiempo? ¿No es bueno usar datetime? El rango es mayor y el espacio de almacenamiento es realmente muy diferente. Date prisa y agrégalo a las especificaciones de desarrollo.

4. ¿Es posible que la zona horaria de los datos de tipo horario sea incorrecta al migrar datos?

Esto es cierto y sigue siendo válido para el tipo de datos de marca de tiempo. Por ejemplo, al usar mysqldump para exportar datos en formato csv, este método de exportación utilizará la zona horaria UTC para leer datos de tipo de marca de tiempo. , lo que significa que la sesión debe configurarse manualmente al importar. time_zone=' 00:00' puede garantizar que la hora sea precisa:

¿Cómo evitarlo? mysqldump también proporciona un parámetro --skip-tz-utc, lo que significa que la conexión para exportar datos no establece la zona horaria UTC y utiliza el valor de la variable del sistema global time_zone de MySQL.

De hecho, mysqldump también usa la zona horaria UTC de forma predeterminada al exportar archivos SQL, y tendrá información de la zona horaria de la sesión en el encabezado del archivo SQL exportado. Esto puede garantizar que se use la misma zona horaria al importar. y exportar archivos SQL, asegurando así que la zona horaria de los datos sea correcta (el archivo csv exportado obviamente no puede contener esta información). Cabe señalar que el parámetro --compact eliminará toda la información del encabezado del archivo sql, así que asegúrese de recordar: el parámetro --compact debe usarse junto con --skip-tz-utc.