Conceptos básicos tres de MySQL: transacción

6 asuntos

6.1 Hable sobre el ACID y el nivel de aislamiento de la transacción.

1 Explique que las tres características de AID son todas para servicios C (consistencia). Las bases de datos generales necesitan utilizar transacciones para garantizar la coherencia de la base de datos.
Es mejor explicar en detalle cuándo es correcto:
ACID es un acrónimo utilizado para describir cuatro características clave de las transacciones de bases de datos, que incluyen:

  • Atomicidad: una transacción debe considerarse como una unidad mínima de trabajo indivisible. Todas las operaciones de toda la transacción se confirman con éxito o se revierten en caso de error. Para una transacción, solo una de ellas no se puede ejecutar. parte de la operación.
  • Consistencia: las transacciones deben garantizar que la base de datos pase de un estado consistente a otro. Coherencia significa que la base de datos debe cumplir restricciones predeterminadas, como las restricciones de integridad de los datos.
  • Aislamiento: se requiere aislamiento entre múltiples transacciones simultáneas para evitar la corrupción de datos. El aislamiento garantiza que durante la ejecución de una transacción, su operación y el estado intermedio generado estén aislados de otras transacciones concurrentes, es decir, la ejecución de una transacción no debe afectar otras transacciones.
  • Durabilidad: una vez que se confirma una transacción, los cambios en los datos son permanentes. Incluso si hay una falla en el sistema, los datos modificados no se perderán.
    Estas cuatro características son necesarias para que las transacciones de bases de datos garanticen la coherencia y confiabilidad de los datos. Se puede considerar que las tres características de A, I y D realizan servicios C (consistencia). Las transacciones deben garantizar la integridad y coherencia de las bases de datos operativas, que es la importancia de ACID.

2 En el estándar SQL se definen cuatro niveles de aislamiento, a saber: . . .

6.2 Supongamos que el primer hilo inicia una transacción y la lee una vez al principio y al final, pero el segundo hilo en el medio modifica los datos que contiene. En este momento, los datos leídos por el primer hilo por segunda vez son hilo dos ¿Datos modificados o premodificados? (importante)

Respuesta: La respuesta a esta pregunta depende del nivel de aislamiento de las transacciones de su base de datos.

Si la transacción del subproceso 2 no se confirma: al leer el nivel de aislamiento no confirmado, los datos se pueden leer, pero los datos modificados por el subproceso 2 no se pueden leer en el nivel de lectura confirmada y RR, y solo se pueden leer los datos modificados datos anteriores.

Si se confirma la transacción del subproceso 2: no hay problema en leer datos no confirmados en este momento, pero al leer el nivel de aislamiento confirmado, se pueden leer los datos modificados, pero en el nivel RR, los datos premodificados se leen. .

En el nivel serializable, todas las transacciones se ejecutan en serie. Si la transacción del primer subproceso se ejecuta primero, solo los datos antes de la modificación se pueden leer en todo el proceso. Después de ejecutarse, el segundo subproceso puede continuar realizando operaciones de modificación posteriores. .

También puedes echar un vistazo al siguiente resumen:

  • Lectura no confirmada: en este nivel, una transacción puede ver datos no confirmados de otras transacciones. Entonces, en su ejemplo, los datos leídos por el hilo uno por segunda vez serán los datos modificados por el hilo dos.
  • Lectura confirmada: en este nivel, una transacción solo puede ver datos que han sido confirmados por otras transacciones. En su ejemplo, si el subproceso dos ha confirmado la transacción antes de la segunda lectura del subproceso uno, entonces el subproceso uno leerá los datos modificados del subproceso dos. Si el subproceso 2 no se ha enviado, entonces el subproceso 1 leerá los datos antes de que el subproceso 2 los modifique.
  • Lectura repetible (lectura repetible): en este nivel, los datos vistos por una transacción son consistentes durante todo el proceso. Es decir, una vez iniciada una transacción, ya no verá las modificaciones de datos realizadas por otras transacciones. En su ejemplo, los datos leídos por el subproceso uno por segunda vez serán los datos antes de que el subproceso dos modifique, independientemente de si el subproceso dos ha confirmado la transacción o no.
  • Serializable: este es el nivel de aislamiento más estricto y requiere que todas las transacciones se ejecuten en serie. Este nivel evita todos los problemas de concurrencia.

Cabe señalar que cuanto mayor sea el nivel de aislamiento, mejor será la coherencia de los datos, pero el rendimiento de la concurrencia puede verse reducido. Por lo tanto, en el sistema real, es necesario seleccionar el nivel de aislamiento apropiado de acuerdo con las necesidades reales y los requisitos de rendimiento.

6.3 Cómo realizar la instantánea de mvcc

Usando el registro de deshacer, el último registro también es una instantánea, a la que apuntará un puntero oculto db_roll_ptr de la fila de datos.

6.4 escribir sql

Hay una tabla de profesores con ID y nombre de campos, y una tabla t_s que representa profesor-estudiante con campos tid y sid. Ahora le permite consultar a los profesores cuyo número de estudiantes es mayor que 10.

seleccione t.name del profesor t left únase a t_s ts en t.id=ts.id grupo por t.id con recuento (ts.sid)>10

6.5 ¿El nivel de aislamiento de la base de datos es solo para operaciones de lectura?

El nivel de aislamiento de la base de datos no es solo para operaciones de lectura, sino también para operaciones de escritura. Pero a menudo prestamos más atención a la coherencia de las operaciones de lectura, porque en un entorno concurrente, diferentes niveles de aislamiento tendrán diferentes impactos en las operaciones de lectura, como lecturas sucias, lecturas no repetibles y lecturas fantasma. Las operaciones de escritura generalmente están garantizadas por el mecanismo de control de concurrencia de la base de datos (como los bloqueos).

6.6 La transacción en sí no puede garantizar la protección de escritura, debe completarse junto con el candado

tienes razón. Las transacciones simplemente proporcionan un mecanismo para garantizar que una unidad lógica de trabajo que consta de un conjunto de operaciones de base de datos se complete por completo o no se complete en absoluto (esta es la atomicidad de una transacción). Pero la transacción en sí no puede evitar que varias transacciones modifiquen los mismos datos al mismo tiempo, lo que puede provocar inconsistencia en los datos.

Para resolver este problema, los sistemas de bases de datos suelen utilizar mecanismos de control de concurrencia, como bloqueos, para evitar conflictos entre transacciones concurrentes. Cuando una transacción intenta modificar un dato, el sistema de base de datos bloqueará los datos para evitar que otras transacciones los modifiquen al mismo tiempo. Hasta que esta transacción se complete (se confirme o revierta) y libere el bloqueo, otras transacciones no pueden modificar estos datos.

Por eso decimos que el nivel de aislamiento de la base de datos proporciona protección contra operaciones de escritura. De hecho, esta protección se implementa mediante el mecanismo de control de concurrencia de la base de datos (como los bloqueos). Los diferentes niveles de aislamiento utilizan diferentes estrategias de control de concurrencia, lo que proporciona diferentes grados de protección de las operaciones de escritura.

6.6.1 Si una transacción se encuentra en el caso de lectura repetible, después de la primera operación de lectura, se utiliza la declaración de actualización para actualizar la operación. En este momento, ¿se regenerará la vista de lectura y luego se actualizará en función de los datos más recientes?

Bajo el nivel de aislamiento de lectura repetible, si la declaración de actualización se usa para actualizar la operación después de una operación de lectura, la vista de lectura no se regenerará. En el nivel de aislamiento de lectura repetible, una transacción genera una instantánea al principio y las operaciones posteriores se realizan sobre la base de esta instantánea. Cuando la transacción ejecuta la declaración de actualización, la operación de actualización se realizará de acuerdo con la instantánea anterior. Incluso si otras transacciones modifican estos datos, los datos vistos por esta transacción siguen siendo los datos cuando se generó la instantánea al principio.

6.6.2 ¿Cuál es el alcance de coherencia de las transacciones de la base de datos mysql?

Recomendación: ¿Cómo entender el concepto de coherencia en las transacciones de bases de datos?
En este artículo, se señala que la coherencia de las transacciones está limitada por la integridad de la base de datos y la integridad de las características comerciales de la capa de aplicación, y las restricciones de concurrencia también son requeridas por las restricciones comerciales de la capa de aplicación, por lo que la granularidad de la consistencia de las transacciones mysql puede ser única La consistencia de los subprocesos también puede ser la consistencia de la concurrencia en subprocesos múltiples, que depende de las necesidades del negocio. Por supuesto, las empresas concurrentes generales deben garantizar este tipo de coherencia concurrente, por lo que bloquea se utilizan para resolver problemas como la sobreventa y la lectura fantasma, pero las empresas de un solo subproceso no necesitan utilizar bloqueos.

6.6.3 En el nivel RR, use la declaración de selección dos veces para consultar el número de saltos de registro en el intervalo relevante, y otra transacción en el medio inserta una declaración en este intervalo. ¿Encontrará un dato más en este intervalo cuando seleccione? este intervalo por segunda vez?

En el nivel RR (lectura repetible), usar la instrucción SELECT dos veces para consultar el mismo conjunto de registros debería devolver el mismo resultado, incluso si hay otras transacciones que insertan registros en este intervalo entre las dos consultas. Porque bajo el nivel de aislamiento RR, una transacción creará una instantánea de datos (vista de lectura) al principio, y las operaciones de lectura posteriores se basan en esta instantánea y no verán las modificaciones realizadas por otras transacciones después de que comience la transacción. Por lo tanto, si otras transacciones insertan nuevos registros después de que comenzó la transacción, la transacción actual no verá estos nuevos registros en consultas posteriores.

Cabe señalar que, si bien el nivel RR puede garantizar que los registros existentes permanezcan consistentes durante una transacción, no impide que otras transacciones inserten nuevos registros. Estos nuevos registros insertados durante la transacción se vuelven visibles cuando se confirma la transacción actual.

Es por eso que el nivel de aislamiento RR no puede evitar por completo las lecturas fantasma. La lectura fantasma se refiere a la aparición o desaparición repentina del conjunto de resultados de una consulta después de que se confirma una determinada transacción . En el nivel RR, las transacciones no ven nuevas filas insertadas por otras transacciones, pero cuando la transacción se confirma, estas nuevas filas se vuelven visibles, lo que puede provocar lecturas fantasma.

7 problemas relacionados con la serialización

7.1 La serialización debe garantizar que los datos leídos sean los más recientes, ¿verdad?

Sí, la serialización es el nivel más alto en el nivel de aislamiento de la base de datos y puede garantizar que las transacciones se ejecuten en serie, evitando así varios problemas causados ​​por transacciones ejecutadas simultáneamente, incluido el problema de que los datos leídos no estén actualizados. En el nivel de serialización, los resultados de la ejecución de las transacciones son los mismos que los resultados de su ejecución en serie.

7.2 ¿La transacción serializada es todo lo que está en la base de datos o la transacción asociada de una determinada tabla?¿Cuál es la granularidad de la serialización?

La granularidad de la serialización depende del sistema de gestión de bases de datos específico y su mecanismo de control de concurrencia. En algunos sistemas de bases de datos, la serialización puede bloquear toda la base de datos, por lo que todas las transacciones deben ejecutarse en serie. En algunos otros sistemas de bases de datos, la serialización solo puede bloquear los datos a los que accede la transacción, de modo que las transacciones que acceden a diferentes datos se pueden ejecutar en paralelo.

¿Cuál es la granularidad de la serialización en MySQL?

El nivel de aislamiento de serialización (SERIALIZABLE) en MySQL bloqueará todas las operaciones de lectura para evitar que otras transacciones modifiquen datos al mismo tiempo, logrando así la ejecución en serie de transacciones. Esto significa que sólo una transacción puede operar con los mismos datos a la vez. Por lo tanto, se puede decir que el nivel de aislamiento de serialización de MySQL se realiza en el nivel de fila de datos y la granularidad específica depende del rango de datos de la operación de transacción.

7.3 ¿Se puede implementar el mecanismo de serialización también en el lado del cliente, como el escenario de consumo de un solo subproceso de la cola de mensajes?

Sí, el mecanismo de serialización no se limita a bases de datos, se puede aplicar a cualquier escenario que requiera control de concurrencia. Por ejemplo, en la cola de mensajes, puede permitir que cada hilo de consumidor procese una parte del mensaje, de modo que los mensajes procesados ​​por diferentes hilos de consumidor no se superpongan, de modo que se pueda lograr un efecto similar a la serialización. Sin embargo, debe tenerse en cuenta que este método depende de la estrategia de distribución del mensaje. Si el mensaje no se puede distribuir uniformemente a cada hilo del consumidor, el hilo del consumidor puede aparecer inactivo, lo que resultará en una disminución en el rendimiento del sistema.

8 ¿Cuáles son las características de las bases de datos y qué están garantizadas e implementadas? (Byte backend)

8.1 Las transacciones de bases de datos tienen las siguientes cuatro propiedades clave, a menudo denominadas propiedades ACID:

  1. Atomicidad : La atomicidad garantiza que una transacción sea una unidad de operación indivisible, ya sea ejecutada en su totalidad o no ejecutada en absoluto. Si alguna parte de una transacción falla, toda la transacción se revertirá al estado original para garantizar la coherencia de los datos. La atomicidad generalmente se implementa mediante un sistema de gestión de bases de datos (DBMS), utilizando registros de transacciones y mecanismos de reversión para garantizarla.

  2. Coherencia : la coherencia garantiza que las transacciones transformen la base de datos de un estado coherente a otro. Esto significa que la base de datos debe satisfacer ciertas restricciones y reglas de integridad antes y después de la ejecución de la transacción para garantizar la integridad de los datos. La coherencia suele estar garantizada por las restricciones de la aplicación y la base de datos.

  3. Aislamiento : el aislamiento garantiza que cuando se ejecutan varias transacciones al mismo tiempo, cada transacción se siente como si fuera la única que se ejecuta y no se verá afectada por otras transacciones. El aislamiento se logra mediante el uso de mecanismos de bloqueo, control de múltiples versiones u otras técnicas de control de concurrencia para evitar carreras de datos y lecturas inconsistentes.

  4. Durabilidad : La durabilidad garantiza que una vez que una transacción se confirma con éxito, sus resultados se almacenarán permanentemente en la base de datos y no se perderán incluso si el sistema falla o se apaga. La persistencia normalmente se logra escribiendo el registro de transacciones en un almacenamiento no volátil, como un disco duro.

8.2 Realización de las cuatro características principales

Juntas, estas propiedades ACID garantizan la confiabilidad transaccional y la integridad de los datos. Internamente, un sistema de gestión de bases de datos implementa estas funciones mediante mecanismos de registro y recuperación. La forma en que se hace esto puede variar, pero generalmente implica los siguientes pasos:

  • Registro de transacciones (registro de transacciones) : la base de datos registra todos los cambios (insertar, actualizar, eliminar) de una transacción en el registro de transacciones para su recuperación cuando sea necesario. Esto incluye registrar todos los cambios antes de realizar la transacción para garantizar la atomicidad y la durabilidad.

  • Control de concurrencia : para lograr el aislamiento, los sistemas de administración de bases de datos utilizan técnicas como bloqueo, marca de tiempo o control de múltiples versiones para administrar transacciones que se ejecutan simultáneamente. Esto garantiza que cada transacción no interfiera con las operaciones de otras transacciones.

  • Revertir (Revertir) : Si alguna parte de la transacción falla o se produce un error, el sistema de base de datos utilizará la información en el registro de transacciones para revertir la transacción al estado anterior para garantizar la atomicidad.

  • Garantía de durabilidad : el sistema de gestión de bases de datos garantiza que los cambios en el registro de transacciones se escriban en un almacenamiento persistente, como un disco duro. Esto garantiza que incluso si el sistema falla o se queda sin energía, los resultados de la transacción no se perderán.

En resumen, las características ACID son las características clave de las transacciones de la base de datos, que se realizan y garantizan mediante el mecanismo interno y la estrategia de recuperación del sistema de gestión de la base de datos. Estas características garantizan la confiabilidad e integridad de los datos, de modo que la base de datos aún pueda mantener la coherencia frente a diversas fallas y accesos simultáneos.

8.3 ¿Cuáles son las garantías ACID de registro de deshacer, registro de rehacer y registro bin para transacciones?

8.4 Nivel de aislamiento de la base de datos:

Los niveles de aislamiento de la base de datos definen la visibilidad y la interoperabilidad entre diferentes transacciones. El estándar SQL define cuatro niveles de aislamiento, de menor a mayor son Lectura no confirmada, Lectura confirmada, Lectura repetible y Serializable.

  1. Lectura no confirmada : permite que una transacción lea modificaciones no confirmadas de otra transacción, que es el nivel de aislamiento más bajo y generalmente no se recomienda porque puede generar lecturas sucias y lecturas no repetibles.

  2. Lectura confirmada : garantiza que una transacción no leerá las modificaciones de otra transacción no confirmada. Este es el nivel de aislamiento predeterminado para la mayoría de los sistemas de bases de datos.

  3. Lectura repetible : garantiza que los datos vistos por una transacción permanezcan consistentes durante la ejecución, incluso si otras transacciones los insertan o modifican mientras tanto. Este es el nivel de aislamiento predeterminado para MySQL.

  4. Serializable : proporciona el nivel de aislamiento más alto, lo que garantiza que no haya problemas de concurrencia entre transacciones, pero el rendimiento suele ser menor.

8.5 La diferencia entre el mecanismo MVCC de los niveles de aislamiento RC y RR:

  1. Nivel de aislamiento RC (lectura comprometida) : bajo el nivel de aislamiento RC, las transacciones pueden leer los datos de las transacciones confirmadas, pero no pueden leer los datos de las transacciones no confirmadas. MVCC hace esto internamente creando una instantánea de cada transacción para garantizar que una transacción no lea los cambios no confirmados de otra transacción.

  2. Nivel de aislamiento RR (lectura repetible) : bajo el nivel de aislamiento RR, las transacciones pueden leer los datos de las transacciones confirmadas y no verán los resultados de las operaciones de inserción, actualización o eliminación de otras transacciones durante toda la transacción. MVCC también entra en juego aquí, pero crea una instantánea al comienzo de una transacción y la mantiene allí durante toda la transacción para garantizar la coherencia de los datos.

8.6 Evite la lectura fantasma bajo el nivel de aislamiento RR (MVCC + bloqueo de siguiente tecla):

La lectura fantasma se refiere a la situación en la que se ejecuta la misma consulta en una transacción, pero el conjunto de resultados es inconsistente porque otras transacciones insertan o eliminan filas que cumplen con las condiciones de la consulta. Bajo el nivel de aislamiento RR, para evitar la lectura fantasma, la base de datos utiliza MVCC y el mecanismo de bloqueo de siguiente clave para manejar.

  • MVCC : MVCC garantiza que las consultas no se vean afectadas por otras transacciones mediante la creación de una instantánea de la transacción. Bajo el nivel de aislamiento RR, la consulta utilizará la instantánea al comienzo de la transacción, lo que significa que la inserción, actualización y eliminación de otras transacciones durante la consulta no afectará los resultados de la consulta.

  • Bloqueo de siguiente tecla : el bloqueo de siguiente tecla es un mecanismo de bloqueo que se utiliza para evitar la lectura fantasma en el nivel de aislamiento RR. Cuando una transacción ejecuta una instrucción SELECT, el bloqueo de siguiente clave bloqueará todos los registros dentro del rango de consulta y también bloqueará el "espacio" de registros que se pueden insertar después de la consulta para evitar la lectura fantasma. Esto garantiza que otras transacciones no puedan insertar nuevos registros que cumplan las condiciones de la consulta durante la consulta.

En resumen, bajo el nivel de aislamiento RR, a través del mecanismo MVCC y Next-Key Locking, la base de datos garantiza la coherencia de la consulta y evita el problema de la lectura fantasma. MVCC proporciona una instantánea para mantener la coherencia de la consulta, mientras que el bloqueo de siguiente clave garantiza que los datos durante la consulta no se verán afectados por las operaciones de inserción de otras transacciones. La combinación de estos dos mecanismos proporciona una garantía de coherencia de los datos en el nivel de aislamiento RR.

8.7 Solo el uso del bloqueo de tecla siguiente puede garantizar evitar la lectura fantasma. ¿No bloquea la tecla siguiente espacios y filas? Es una combinación de bloqueos de fila y bloqueos de espacio, por lo que no se debe permitir que otras transacciones se modifiquen, y luego simplemente se puede ¿Se garantiza la lectura fantasma? ¿Pero puede garantizar una lectura repetible?

8.8

Supongo que te gusta

Origin blog.csdn.net/yxg520s/article/details/132517178
Recomendado
Clasificación