Registro de aprendizaje de la base de datos de reclutamiento de otoño de 2020 (mysql)

Resumen de optimización de consultas y índices de MySQL

índice

Un índice es una estructura para ordenar los valores de una o más columnas en una tabla de base de datos. El uso de un índice puede acceder rápidamente a información específica en una tabla de base de datos.

Índice ordinario e índice único

Tanto el índice único como el índice ordinario utilizan estructuras de árbol B, y la complejidad del tiempo de ejecución es O (logn).

La única tarea de un índice ordinario (un índice definido por la palabra clave KEY o INDEX) es acelerar el acceso a los datos . Por lo tanto, solo debe crear índices para las columnas de datos que aparecen con mayor frecuencia en condiciones de consulta (WHEREcolumn =) o condiciones de clasificación (ORDERBYcolumn). Siempre que sea posible, debe elegir una columna de datos con los datos más prolijos y compactos (como una columna de datos de tipo entero) para crear un índice.

Los índices ordinarios permiten que la columna de datos indexados contenga valores duplicados. Si puede determinar que una columna de datos solo contendrá valores que sean diferentes entre sí, debe usar la palabra clave UNIQUE para definirla como un índice único al crear un índice para esta columna de datos.
Los beneficios de hacerlo: Primero, simplifica la administración de MySQL de este índice y este índice se vuelve más eficiente. Segundo, MySQL verificará automáticamente el valor de este campo en el nuevo registro cuando se inserte un nuevo registro en la tabla de datos. ¿Ha aparecido ya en este campo de un registro? Si es así, MySQL se negará a insertar ese nuevo registro. En otras palabras, el índice único puede garantizar la unicidad de los registros de datos. De hecho, en muchas ocasiones, el propósito de crear un índice único a menudo no es mejorar la velocidad de acceso, sino evitar la duplicación de datos .

restricción

La diferencia entre restricción de clave primaria y restricción única

Tanto las restricciones de clave primaria como las restricciones únicas crearán índices únicos. La diferencia es que no se permite que la clave de índice de la restricción de clave primaria (índice único) sea NULL en definición, y que la clave de índice de la restricción única (índice único) sea NULL en definición.

Restricción de clave primaria	Restricción única
La columna no permite valores nulos (NULL)	La columna en la que se ubica permite valores nulos (NULL)
Solo puede haber una restricción de clave principal en una tabla	Puede haber varias restricciones únicas o una

La diferencia entre clave primaria, clave externa e índice

El papel de la clave principal y la clave externa de SQL

• La clave principal es un identificador único que puede determinar un registro. Por ejemplo, un registro incluye el número de identificación, el nombre y la edad. El número de identificación es el único que lo identifica a usted. Otros pueden repetirse, por lo que el número de identificación es la clave principal.
• La clave externa se usa para asociarse con otra tabla. Es un campo que puede confirmar registros de otra tabla y se utiliza para mantener la coherencia de los datos. Por ejemplo, si un campo de la tabla A es la clave principal de la tabla B, puede ser una clave externa de la tabla A.

Definición: Clave principal: identifica de forma única un registro, no se puede repetir y no puede estar vacío.
Clave externa: la clave externa de una tabla es la clave principal de otra tabla. La clave externa se puede repetir y puede ser nula.
Índice: el campo no tiene valores duplicados, pero puede tener un valor nulo.

Rol:
Clave principal: utilizada para garantizar la integridad de los datos
Clave externa: utilizada para establecer contacto con otras tablas
Índice: utilizado para mejorar la velocidad de clasificación de consultas

Número:
Clave principal: solo puede haber una clave principal.
Claves externas: una tabla puede tener varias claves externas.
Índice: una tabla puede tener varios índices únicos.

Tres paradigmas de diseño de bases de datos

Tres paradigmas de bases de datos (importante)
La explicación más simple de los tres paradigmas de bases de datos

1. La primera forma normal: la atomicidad de los campos (columnas) es indivisible.
   El primer paradigma es el requisito más básico de todas las bases de datos relacionales. El primer paradigma requiere que las tablas de la base de datos sean bidimensionales, no tridimensionales (es decir, cada campo no se puede dividir).

2. Segunda forma normal: Sobre la premisa de satisfacer la primera forma normal. Todos los campos, excepto la clave principal, deben depender completamente del campo de clave principal.

3. El tercer paradigma: sobre la premisa de satisfacer el segundo paradigma. Los campos de clave no primaria no pueden depender entre sí. Cada columna tiene una relación directa con la clave principal y no hay dependencia transitiva.
   El segundo paradigma y el tercer paradigma son principalmente para evitar la redundancia de datos, las excepciones de inserción y las excepciones de eliminación. Generalmente, divida la tabla de modo que las tablas múltiples después de la división se encuentren con la segunda y tercera forma normal.
   Primera forma normal: Ejemplos que no cumplen con la primera forma normal:

   表：字段1、 字段2(字段2.1、字段2.2)、字段3 ......
   

Segunda forma normal: Ejemplos que no cumplen con la segunda forma normal:

    表：学号、课程号、姓名、学分;

    这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键，这里学分依赖课程号，姓名依赖与学号，所以不符合二范式。

Tercera forma normal: Ejemplos que no cumplen con la tercera forma normal:

     表：学号、姓名、 年龄、 所在学院、学院联系电话、学院联系电话

      存在依赖传递: (学号) → (所在学院) → (学院地点, 学院电话)

Preguntar

La diferencia entre árbol b y árbol b +

¿Por qué los sistemas de archivos y las bases de datos utilizan árboles b / b + para indexar?

Los datos de la base de datos generalmente se almacenan en el disco, y la E / S de los datos en el disco consume más tiempo que la E / S de los datos en la memoria, por lo que la cantidad de E / S del disco debe reducirse.

El número de E / S depende de la altura del árbol. En comparación con el árbol rojo-negro, el nodo del árbol b / b + puede tener varios hijos (el número máximo de hijos del nodo se denomina orden del árbol B), lo que hace que la altura del árbol sea mucho menor que la del árbol rojo-negro, lo que reduce el número de E / S.

El tiempo de operación en el árbol B / B + generalmente está compuesto por el tiempo de acceso al disco y el tiempo de cálculo de la CPU. La CPU es muy rápida, por lo que la eficiencia de operación del árbol B depende del número de veces que se accede al disco. El número total de palabras clave es el mismo. Cuanto menor sea la altura del árbol B inferior, menos tiempo llevará la E / S del disco.

¿Por qué el árbol B + es más adecuado para la indexación de bases de datos que el árbol B?

El árbol B + es una especie de árbol deformado de árbol B generado por el sistema de archivos (el nivel de directorio y el índice de nivel del archivo, solo el nodo de hoja inferior (archivo) guarda los datos) los nodos que no son de hoja solo guardan el índice, no el actual Los datos se almacenan en los nodos hoja.
¡Todos los nodos que no sean hojas pueden considerarse partes de índice!

Por que mysql usa árbol B +

• ¿Por qué no usar hash -> desordenado
  Hash es más rápido que un árbol independientemente de la lectura o escritura, entonces, por qué debería usarse una estructura de árbol para la estructura del índice? Porque para la agrupación, clasificación y comparación, la complejidad temporal del índice hash se degradará a O (n), y este tipo de consulta aparecerá a menudo en los negocios reales .

• ¿Por qué no usar un árbol binario ?> La cantidad de
  nodos es alta, la altura del árbol es alta. Cada nodo del árbol binario solo tiene dos bifurcaciones y cada nodo solo puede almacenar un registro. A medida que aumenta la cantidad de datos, la altura del árbol aumentará significativamente y la altura del árbol Cuanto mayor sea el valor, más lenta será la velocidad de consulta . En el árbol B, cada nodo puede tener varias bifurcaciones y puede almacenar varios registros, por lo que la altura del árbol se reduce y puede dar rienda suelta al principio de localidad. El llamado principio de localidad consiste en utilizar los datos cercanos a los datos de la consulta con alta probabilidad. Este principio se basa en la lectura anticipada del disco, que puede reducir la E / S del disco.

• ¿Por qué no utilizar el árbol B -> Cada nodo almacena datos? Las consultas deben atravesar el
  árbol B en cada capa. El número de nodos es muy grande y el número de capas es muy pequeño. En comparación con el árbol binario, el número de E / S de disco se reduce, pero cada nodo almacena datos. , La consulta debe recorrerse en orden, que no es la mejor manera de ubicar datos rápidamente .

• ¿Por qué utilizar el árbol B + en lugar del árbol B? El árbol
  B + se mejora sobre la base del árbol B. Los datos solo se almacenan en los nodos hoja y se agrega una lista enlazada entre los nodos hoja. De esta manera, al obtener los nodos, no se requiere un recorrido en orden, lo cual es conveniente para La ubicación de datos es la mejor manera de reducir la E / S del disco .
  
  ¿Por qué el índice de la base de datos MySQL elige usar el árbol B +?
  PD: Vi a alguien decir esto en Zhihu, y siento que tiene sentido:
  piensan que la razón principal por la que el índice de la base de datos usa el árbol B + es: el árbol B no resuelve el elemento mientras mejora el rendimiento de IO Para resolver el problema del recorrido ineficiente, nació la aplicación del árbol B +. El árbol B + solo necesita atravesar los nodos de las hojas para atravesar todo el árbol. Además , las consultas basadas en rangos en la base de datos son muy frecuentes y el árbol B no admite tales operaciones o es demasiado ineficiente .

asuntos

La llamada transacción es controlar un conjunto de operaciones (que consta de una o más declaraciones SQL) de la base de datos . Si alguna de estas declaraciones no se puede ejecutar, no se ejecutará ninguna de las declaraciones. En otras palabras, todas las declaraciones de la transacción se ejecutan o no se ejecutan (atómicas).

El proceso de usar transacciones en la base de datos mysql

• strart transaction;Asuntos abiertos`` begin;, set autocommit=1;(el predeterminado).
• Transacción de control, el valor predeterminado es autocommit, es decir, autocommit = 1; desactive el autocommit select @@autocommit;o set autocommit=0;, después de desactivar el autocommit, puede realizar una operación de reversión, es decir, reversión.
• Confirme la transacción manualmente commit;, una vez que la transacción se confirma, no se puede deshacer (persistencia).
• Revertir manualmente la rollback;transacción .

Características de la transacción ACID

Transacción tiene una definición muy estricta, debe cumplir con 4 características al mismo tiempo, a saber: Atomicidad (Atomicidad), consistencia (Consistencia), aislamiento (Aislamiento), durabilidad (Durabilidad), referido como el estándar ACID para transacciones.

• Atomicidad A : La transacción debe ser considerada como una unidad de trabajo mínima indivisible Solo cuando todas las operaciones de la base de datos en la transacción se ejecutan con éxito, la transacción completa puede considerarse exitosa. Si alguna instrucción SQL en la transacción no se ejecuta, la instrucción SQL ejecutada con éxito también debe cancelarse y el estado de la base de datos vuelve al estado anterior a la ejecución de la transacción.
  Por ejemplo: Supongamos que el usuario A transfiere 100 yuanes al usuario B. La transacción requiere la ejecución de dos declaraciones SQL, es decir, el usuario A deduce 100 yuanes y el usuario B aumenta 100 yuanes. Estas dos declaraciones deben tener éxito o fallar al mismo tiempo, de lo contrario los datos serán inconsistentes. .

• Consistencia C : Consistencia significa que la transacción debe cambiar la base de datos de un estado consistente a otro estado consistente, es decir, una transacción debe estar en un estado consistente antes y después de la ejecución.
  La consistencia se inclina más a la consistencia del estado de la base de datos antes y después de la ejecución de la transacción, y la atomicidad se inclina a la indivisibilidad de la transacción, se puede considerar que la consistencia de la transacción está garantizada por la atomicidad.
  Por ejemplo: suponga que la suma del dinero del usuario A y del usuario B es 3000, entonces no importa cómo se transfiera el dinero entre A y B, y cuántas transferencias, la suma del dinero de los dos usuarios debería ser 3000 después de que finalice la transacción.

• Aislamiento I : la transacción abierta por la base de datos para cada usuario no puede ser perturbada por los datos de operación de otras transacciones, y múltiples transacciones concurrentes deben aislarse entre sí.
  Por ejemplo: cuando varios usuarios operan la misma tabla, la transacción abierta por la base de datos para cada usuario no puede ser interferida por las operaciones de otras transacciones, y varias transacciones concurrentes deben aislarse entre sí.
  Por ejemplo: para dos transacciones concurrentes T1 y T2. Desde la perspectiva de la transacción T1: T2 termina antes de que comience T1 o T2 comienza después de que termina T1. En otras palabras: cada transacción no siente que se estén ejecutando otras transacciones al mismo tiempo.

• Persistencia : Una vez comprometida la transacción, los cambios realizados se guardarán permanentemente en la base de datos, aunque la base de datos falle, no debería tener ningún impacto en ella. Cabe señalar que la durabilidad de una transacción no puede ser 100% duradera, y solo se puede garantizar desde la perspectiva de la transacción en sí, y algunas razones externas hacen que la base de datos falle, como el daño del disco duro, entonces los datos enviados pueden perderse .

Nivel de aislamiento de la transacción mysql

Tutorial de operación práctica de la base de datos MySQL (18) -transacción de la base de datos y su nivel de aislamiento -> ¡dio muchos buenos ejemplos!

¿Por qué las transacciones deben establecer el nivel de aislamiento?

En circunstancias normales, varios subprocesos acceden a la base de datos simultáneamente, por lo que es fácil tener múltiples subprocesos abiertos transacciones al mismo tiempo. En este caso, pueden producirse lecturas sucias, lecturas repetidas y lecturas fantasmas. Para evitar esta situación, es necesario establecer el nivel de aislamiento para la transacción.

Cuatro niveles de aislamiento de transacciones

• READ UNCOMMITTED, read no confirmado (existe una lectura sucia), debe evitarse en el desarrollo real
• READ COMMITTED, la lectura se ha confirmado (se pueden evitar las lecturas sucias, pero las lecturas no se pueden repetir)
• LECTURA REPETIBLE, lectura repetible (resolver lectura no repetible), nivel de aislamiento predeterminado de mysql
  PS: Pero en teoría, las lecturas fantasmas ocurrirán en este nivel. Sin embargo, el motor de almacenamiento de MySQL resuelve este problema a través del mecanismo de control de concurrencia de múltiples versiones (MVCC), por lo que este nivel puede evitar la lectura fantasma . mysql está en el nivel RR, Innodb usa MVCC y bloqueos de siguiente tecla para resolver lecturas fantasmas.
• SERIALIZABLE, serializable
  PS: El nivel de aislamiento más alto de la transacción, obligará a que la transacción se clasifique para que no entre en conflicto, resolviendo así los problemas de lecturas sucias, lecturas fantasmas y lecturas repetidas. Sin embargo, este nivel puede causar muchos tiempos de espera y contención de bloqueos, y rara vez se usa en aplicaciones reales.

Ver y modificar operaciones

Ver el nivel de aislamiento de la base de datos (versión de mysql 8.0):
nivel de select @@global.transaction_isolation;
sesión de nivel de sistema select @@transaction_isolation;o select @@session.transaction_isolation;
modificar el nivel de aislamiento:
set <global/session> transaction isolation level <READ UNCOMMITTED/READ COMMITTED/REPEATABLE READ/SERIALIZABLE>

Lectura sucia

Una transacción lee datos que no fueron confirmados por otra transacción.

¡Lea los datos no confirmados del hilo A en la operación de transacción en el hilo B! ! En este punto, la transacción del subproceso A puede usar la reversión ROLLBACK para deshacer la operación anterior. ¡Esto es bastante peligroso! Esto es como: El hilo A es el cliente y el hilo B es el vendedor; porque el vendedor de lectura sucia pensó erróneamente que había recibido el dinero del cliente e inmediatamente envió la mercancía, pero el cliente canceló la transferencia anterior retrocediendo.

No repetible

La lectura no repetible son los resultados de lectura inconsistentes cuando los datos enviados por otros subprocesos se leen repetidamente en una transacción . El motivo de este problema es que otras transacciones han realizado operaciones de actualización durante el proceso de consulta . Por ejemplo, cuando el banco realiza un informe estadístico, la primera consulta del número de cuenta 9527 tiene 1.000 yuanes, y la segunda consulta de la cuenta 9527 tiene 900 yuanes; el motivo es que el titular de la cuenta 9527 lo sacó durante el período estadístico en el que el banco hizo el extracto. 100 yuanes, esto dará lugar a resultados inconsistentes de múltiples informes estadísticos.
Las lecturas no repetibles son similares a las lecturas sucias, pero las lecturas sucias leen los datos sucios no confirmados de las transacciones de otros subprocesos. Las lecturas no repetibles son situaciones en las que los datos enviados por otros subprocesos se leen repetidamente dentro de la transacción, pero los datos no son consistentes.

Lectura fantasma

La lectura fantasma se refiere al número inconsistente de filas de datos en dos consultas dentro de una transacción . La razón de este problema es que otras transacciones han agregado operaciones durante el proceso de consulta . Por ejemplo, cuando el banco cuenta el monto total de todos los usuarios en la tabla de cuentas al realizar un informe estadístico, hay tres cuentas con un monto total de 3000. En este momento, se agregó una nueva cuenta y se depositaron 1,000 yuanes; en este caso, el banco encontró que el monto total de la cuenta se había convertido en 4,000, lo que provocó una lectura fantasma.

Mecanismo MVCC de mysql

Introducción

El principio e implementación del mecanismo MySQL InnoDB MVCC y la implementación de
MVCC (Multiversion Concurrency Control), control de concurrencia de múltiples versiones, es un medio común para manejar conflictos de lectura y escritura en la implementación de motores de bases de datos modernas (incluyendo MySQL, Oracle, PostgreSQL, etc.) , con el propósito de mejorar la alta concurrencia de bases de datos. El rendimiento de rendimiento bajo la escena.

Lo opuesto a MVCC es el control de concurrencia basado en bloqueos. La mayor ventaja de MVCC: leer sin bloqueo, leer y escribir sin conflictos. En las aplicaciones OLTP (procesamiento de transacciones en línea) con más lecturas y menos escrituras, es muy importante que las lecturas y escrituras no entren en conflicto, lo que aumenta en gran medida el rendimiento simultáneo del sistema.

• El motor InnoDB en MySQL es compatible con MVCC;
• Para lidiar con transacciones concurrentes altas, MVCC es más efectivo que los bloqueos de fila simples y tiene una sobrecarga más baja;
• MVCC funciona bajo los niveles de aislamiento de lectura confirmada y lectura repetible ;
• MVCC se puede implementar en base a un bloqueo optimista y pesimista.

PD: La realización del bloqueo pesimista es el bloqueo; hay dos realizaciones principales del bloqueo optimista: mecanismo CAS (operación atómica) y mecanismo de número de versión.

Principio de implementación

Principio de realización de MYSQL MVCC
MVCC se realiza guardando dos columnas ocultas detrás de cada registro de fila. De estas dos columnas, una contiene el tiempo de creación de la fila y la otra el tiempo de vencimiento (o tiempo de eliminación) de la fila. Por supuesto, lo que se almacena no es el valor de tiempo real, sino el número de versión del sistema (número de versión del sistema) . Cada vez que se inicia una nueva transacción, el número de versión del sistema se incrementa automáticamente. El número de versión del sistema al comienzo de la transacción se utilizará como el número de versión de la transacción que se comparará con el número de versión de cada fila de la consulta .

Resumen: MVCC (control de concurrencia de múltiples versiones) es una forma de retener temporalmente varias versiones de los mismos datos para lograr el control de concurrencia.

El nivel de aislamiento RR resuelve la lectura fantasma en la situación actual de lectura e instantánea de lectura

Lectura actual y lectura instantánea -> Interpretación de la diferencia entre instantánea y lectura actual
En un sistema concurrente que admita MVCC, necesitamos admitir dos tipos de lecturas, una es lectura instantánea y la otra lectura actual.

• Lectura de instantánea: operación de selección simple. Lo que se lee es la versión visible de los datos registrados (pueden ser datos desactualizados) sin bloqueo.
• Lectura actual: operaciones de lectura especiales, operaciones de inserción / actualización / eliminación. Lo que se lee es la última versión de los datos del registro, y el registro devuelto por la lectura actual se bloqueará para garantizar que otras transacciones no modifiquen este registro al mismo tiempo.

En el nivel RR (lectura repetible), la lectura de la instantánea se logra a través de MVVC (control de múltiples versiones) y deshacer el registro, y la lectura actual se logra agregando bloqueo de registro (bloqueo de registro) y bloqueo de espacio (bloqueo de espacio).

¿Cómo resuelve InnoDB la lectura fantasma?
Conclusión: Bajo el nivel de aislamiento de RR, Innodb usa MVCC y bloqueos de siguiente tecla para resolver lecturas fantasmas. MVCC resuelve lecturas fantasmas para lecturas normales (lecturas instantáneas), y los bloqueos de siguiente tecla resuelven lecturas fantasmas bajo las condiciones de lectura actuales.

PD: En el modo RC, MVCC no puede resolver lecturas fantasmas y lecturas no repetibles, porque cada lectura leerá su propia versión de instantánea actualizada. En pocas palabras, otra transacción se confirma y se actualiza una vez para leer la última.

motor mysql y diferencia

motor mysql

El motor de base de datos es el servicio principal que se utiliza para almacenar, procesar y proteger datos . El motor de la base de datos se puede utilizar para controlar los derechos de acceso y procesar rápidamente las transacciones, cumpliendo así los requisitos de la mayoría de las aplicaciones que necesitan procesar grandes cantidades de datos en la empresa. Utilice el motor de base de datos para crear una base de datos relacional para el procesamiento de transacciones en línea o el análisis y procesamiento de datos en línea. Esto incluye la creación de tablas para almacenar datos y objetos de base de datos (como índices, vistas y procedimientos almacenados) para ver, administrar y proteger la seguridad de los datos.

Los motores mysql más utilizados son InnoDB y MyISAM.

La diferencia entre InnoDB y MyISAM

Conmutador de motor de base de datos mysql (InnoDB, MyISAM)
La versión 5.7 de mysql instalada en el sistema se show engines;utiliza para ver el motor de mysql. Puede ver que el motor admitido predeterminado es InnoDB, que presenta: Admite transacciones (transacciones), bloqueo de nivel de fila (bloqueos de fila) y claves externas (claves externas).
actualizar, insertar, eliminar la
transacción distribuida de Mysql XA (transacción entre bases de datos) Introducción a MySQL XA
savepoint es un método para implementar "subtransacciones" en el procesamiento de transacciones de bases de datos, también conocido como transacciones anidadas. La transacción se puede revertir al punto de guardado sin afectar los cambios antes de que se creara el punto de guardado. No es necesario abandonar toda la transacción. Conceptos básicos de MySQL: la aplicación de SAVEPOINT

bloqueo de mysql

El entrevistador me preguntó si conocía el bloqueo de MySQL. Los siguientes 15 minutos le hicieron mirarlo con admiración.

• El bloqueo de tabla es el bloqueo granular más grande en el bloqueo de mysql, lo que significa que la operación actual bloquea toda la tabla, el costo del recurso es menor que el bloqueo de fila y no habrá un punto muerto, pero la probabilidad de conflicto de bloqueo es alta.
• Los bloqueos de fila son los bloqueos granulares más pequeños en los bloqueos de mysql. Debido a que la granularidad del bloqueo es muy pequeña, la probabilidad de contención de recursos también es la más pequeña y el rendimiento simultáneo es el más grande, pero también provocará interbloqueos. Cada bloqueo se bloquea y se libera. La sobrecarga también aumentará.

Los bloqueos de fila también se dividen en bloqueos compartidos (bloqueos S o bloqueos de lectura) y bloqueos exclusivos (bloqueos X o bloqueos de escritura) según su uso.

• Cerradura compartida

Instrucciones de uso: Si la transacción A agrega un bloqueo S al objeto de datos 1, la transacción A puede leer el objeto de datos 1 pero no puede modificarlo. Otras transacciones solo pueden agregar un bloqueo S al objeto de datos 1, pero no pueden agregar un bloqueo X hasta que se libere la transacción A. S bloqueo en el objeto de datos 1. Esto asegura que otras transacciones puedan leer el objeto de datos 1, pero no puedan realizar ningún cambio en el objeto de datos 1 antes de que la transacción A libere el bloqueo S en el objeto de datos 1.
Uso: seleccione ... bloquear en el modo de compartir; un
bloqueo compartido significa que varias transacciones pueden compartir un bloqueo para los mismos datos y pueden acceder a los datos, pero solo pueden leerlos pero no modificarlos.

• Cerradura exclusiva

Instrucciones de uso: si la transacción A agrega un bloqueo X al objeto de datos 1, la transacción A puede leer el objeto de datos 1 o modificar el objeto de datos 1, y otras transacciones ya no pueden bloquear el objeto de datos 1 hasta que la transacción A libere el objeto de datos 1 bloquear. Esto asegura que otras transacciones ya no puedan leer y modificar el objeto de datos 1 antes de que la transacción A libere el bloqueo en el objeto de datos 1.
seleccione… para actualizar;
Los bloqueos exclusivos no pueden coexistir con otros bloqueos. Por ejemplo, si una transacción adquiere un bloqueo exclusivo en una fila de datos, otras transacciones ya no pueden adquirir otros bloqueos en la fila.

base de datos redis

La diferencia entre redis y mysql