Un chico de 20 años es pobre, y una chica de 20 años está en su mejor momento. Nadie estará siempre en la flor de la vida, y nadie será siempre pobre...
Directorio de artículos
1. Características del índice MySQL (énfasis)
1. Disco, SO, MySQL, la relación entre los tres al realizar E/S de datos
1.
MySQL brinda a los usuarios servicios de acceso a datos, pero los datos se almacenan en los periféricos de disco de la máquina Linux y la eficiencia de lectura del disco es relativamente baja. ¿Cómo realiza MySQL el acceso a datos para mejorar la eficiencia? Este es un tema importante.
A nivel de hardware, la unidad básica de un bloque de datos es un sector de 512 bytes, pero cuando el sistema operativo realiza operaciones de E/S con el disco, ¿utiliza directamente el sector como unidad básica para realizar operaciones de E/S de datos? ¡Por supuesto que no! Si el sistema interactúa directamente con el tamaño del sector provisto por el hardware, el código IO del SO estará fuertemente relacionado con el hardware, pero no queremos mejorar el grado de acoplamiento, porque una vez que el grado de acoplamiento es alto, el hardware cambia. el código de software en consecuencia. Al mismo tiempo, el tamaño de E/S único de 512 bytes sigue siendo demasiado pequeño, lo que aumentará la cantidad de E/S, lo que resultará en una disminución de la eficiencia, y la unidad de E/S básica del sistema de archivos del sistema operativo real no es un sector, sino un bloque, el tamaño básico es de 4 KB, que es el tamaño de 8 sectores leídos y escritos cada vez.
Cuando MySQL interactúa con el disco, el tamaño de la unidad básica de datos es de 16 KB, lo que en MySQL se denomina página (tenga en cuenta que se distingue de la página del sistema, que es de 4 KB). Aunque estamos hablando de la interacción entre MySQL y el disco, pero la capa de software que puede interactuar con el disco solo debe ser el sistema operativo, por lo que cada vez que MySQL y el disco interactúan con una página de 16 KB, los archivos de datos en MySQL se almacenan en el disco en unidades de páginas.
Cuando el servidor MySQL se ejecuta en la memoria, el servidor solicitará un gran espacio de memoria de grupo de búfer para almacenar en caché varias páginas de archivos de datos, es decir, el sistema operativo interactúa con el disco a través de IO, y el sistema operativo realmente realiza IO con el disco. La unidad de tiempo es 4KB, pero a MySQL no le importan estas cosas, MySQL solo piensa que cuando interactúa con el disco, interactúa con el tamaño de 16KB.
2. Comprensión del índice
1.
El siguiente es un usuario de tabla con un índice de clave principal que creé. Al insertar datos, en realidad inserté la identificación fuera de orden, pero al consultar, todos los registros se ordenan. ¿Quién hizo este trabajo? ¿Cuál es la razón para esto?
2.
¿Por qué la unidad básica de interacción entre MySQL y el disco IO es la página? ¿Está bien cargar tanto como quieras? Por supuesto, esto no es posible. Si desea consultar el registro con id 1, necesita un IO y debe realizar 5 IO para consultar los datos de toda la tabla, lo que será muy ineficiente. Si se guardan varios registros en la tabla en una página, una página se carga directamente en el grupo de búfer durante la E/S real, de modo que cuando se consulta más tarde, no hay necesidad de realizar E/S, y el grupo de búfer en la memoria se lee directamente. se pueden recuperar, y de acuerdo con el principio de localidad, existe una alta probabilidad de que los datos a los que se acceda la próxima vez también estén en esta página. Al leer la próxima vez, existe una alta probabilidad de que IO no se use, y los datos se leerá directamente en la página en el grupo de búfer actual.Es suficiente para obtener datos, por lo que la eficiencia será alta, porque sabemos que la razón principal de la baja eficiencia de E/S no es el tamaño de un solo dato de E/S, sino el número de veces de IO, porque en comparación con el software, el hardware lleva tiempo Hay muchas diferencias.
3.
Cuando entendemos la página, no podemos entender la página simplemente como un bloque de memoria que almacena datos. La página puede entenderse como un objeto de estructura que almacena parte de los datos en la tabla. Entre cada página, use "estructura de datos" Conectar y gestionar juntos.
El almacenamiento de datos dentro de una sola página se ordena de manera ordenada, de hecho, los datos ordenados se conectan uno por uno en forma de una lista enlazada.
4.
Sabemos que los registros dentro de una sola página están conectados de acuerdo con la lista enlazada. En este momento, al buscar un determinado registro, es necesario recorrer uno por uno para encontrarlo. Por ejemplo, primero recorrer las páginas uno por uno, dentro de cada página Iterando a través de los registros uno por uno y comparando con cada registro hasta que la comparación encuentre el registro a buscar, la eficiencia debe ser muy baja. Porque ya sea entre páginas o páginas interiores, necesitamos recorrer linealmente hasta encontrar el registro que estamos buscando a través de la comparación.
5.
Por lo tanto, para mejorar la velocidad de búsqueda, es necesario introducir el concepto de directorio de páginas y localizar rápidamente la ubicación del registro en sí mismo a través del directorio. Por ejemplo, un libro tiene 500 páginas, incluidos 50 directorios, y cada directorio administra el contenido de 10 páginas, luego 50 entradas pueden administrar todo el libro. En el pasado, para buscar el contenido de una determinada página, necesitaba buscar 500 veces en el peor de los casos. Ahora necesita buscar hasta 60 veces. Primero recorra el directorio, y luego recorra las 10 páginas que maneja el directorio. Entonces, lo peor es buscar 60 veces. ¿No mejora esto la eficiencia de la búsqueda?
6.
Por lo tanto, para mejorar la eficiencia de la búsqueda, podemos introducir un directorio de páginas dentro de una sola página para mejorar la eficiencia de la búsqueda de registros dentro de una página. Entonces, ¿esto también puede explicar por qué cuando creamos una tabla con un índice de clave principal, los registros de datos insertados se ordenan de forma predeterminada? De hecho, es para mejorar la eficiencia de la búsqueda, porque el directorio es significativo solo cuando los registros están ordenados.
Cuando la tabla almacena demasiados datos, el tamaño de una sola página se fija en 16 KB y se deben necesitar varias páginas para almacenar los datos correspondientes. También usamos listas vinculadas para administrar varias páginas, pero cuando realizamos un recorrido lineal entre páginas, es también causará una baja eficiencia, porque cuando la página se recorre linealmente, necesita realizar E/S de disco, y la E/S de disco lleva más tiempo, entonces, ¿cómo resolver este problema? Aún con la idea anterior, ¡introduce el directorio de páginas!
Podemos agregar una página que almacene el directorio de la página sobre la base de varias páginas. En este momento, cada página ya no almacena datos en el interior, sino que solo almacena elementos del directorio. Cada elemento del directorio almacena el valor clave mínimo de cada página ordinaria. y el dirección de la página del directorio, por lo que los datos almacenados en la página ordinaria son datos de usuario, y los datos almacenados en la página del directorio son el valor clave mínimo y la dirección de la página ordinaria en la página ordinaria, y el valor clave entre cada ordinario La página también debe estar ordenada, porque la página del directorio administra varias páginas.
Si hay demasiadas páginas de catálogo de nivel superior y es necesario recorrerlas, podemos agregar otra página de catálogo sobre la base de la página de catálogo para administrar las páginas de catálogo de segundo nivel.
El tamaño de datos que una página puede guardar es de 16 KB, y el número de bytes que ocupa una página es en realidad 16 bytes, es decir, cuatro punteros, anterior y siguiente, apuntan a las páginas anterior y siguiente, y un puntero apunta al nodo principal. de la lista enlazada que almacena datos de usuario, el otro puntero apunta al nodo principal del directorio de páginas, por lo que el número de páginas que puede administrar una página de directorio es 16 × 1024 ÷ 16, es decir, 1024 páginas, y la unidad de medida convertida en datos es 1024 16 KB, es decir, 16 MB Para datos, la cantidad de páginas de directorio en la segunda capa que puede administrar la página de directorio de nivel superior es 1024 directorios de página, por lo que la mayoría de los datos administrados en un árbol B+ como el de arriba es de 1024×16MB de datos, es decir, 16GB de datos.
7.
En un árbol B+ real, solo los nodos de hoja están conectados por una lista enlazada, y no existe una relación de conexión entre los nodos que no son de hoja. Por lo general, al buscar, realizaremos una búsqueda de rango. Si los nodos de hoja están conectados, es relativamente Es conveniente para la búsqueda de rango.Si no está conectado, si el nodo de hoja buscado actualmente no es el nodo de hoja de destino, debe buscar nuevamente de arriba a abajo hasta encontrar el nodo de hoja correcto, lo cual es muy ineficiente .
Los nodos de hoja son responsables de almacenar los datos del usuario, los nodos que no son de hoja solo almacenan entradas de directorio y cada entrada de directorio es responsable de administrar un nodo de hoja. Entonces, el árbol B+ es un árbol corto y gordo, porque una capa de nodos que no son hojas puede manejar muchos nodos hoja, y ser corto y gordo es una gran ventaja para el árbol B+, porque los nodos que pasan por el camino para encontrar el nodo hoja de destino Cuanto menor sea el número de puntos, menos páginas realizarán E/S desde el disco y mayor será la eficiencia de la búsqueda. Al mismo tiempo, también tenemos el diseño del directorio de páginas, que puede mejorar en gran medida la eficiencia de la búsqueda a nivel de datos de recorrido.
8.
Incluso si la tabla creada no tiene índice, la adición, eliminación, consulta y modificación de la tabla aún se realizan bajo la estructura de árbol B+ correspondiente a la tabla, porque si no especifica el valor de índice de la tabla, la tabla también tendrá su propia clave principal predeterminada. Es solo que cuando consulta, atraviesa los nodos de hoja linealmente para la consulta, y no usa la estructura de árbol B + para la consulta, porque no ha creado un determinado campo de columna como un valor de índice, por lo que se consulta la tabla sin índice. El motivo de la lentitud es que la complejidad de tiempo es O(N)
y cada tabla tendrá una estructura de datos de árbol B+ correspondiente.
9.
B-tree no tiene ninguna ventaja cuando se enfrenta a la búsqueda de rango.Al mismo tiempo, debido a que cada nodo de B-tree tendrá un valor de datos, cada nodo que no sea hoja administrará menos nodos de hoja, por lo que B-tree es más alto que B+, al buscar de arriba a abajo, la cantidad de IO será mayor y la eficiencia será menor.
3. Índice agrupado (índice y datos juntos) e índice no agrupado (índice y datos se almacenan por separado)
1.
MyISAM utiliza un índice no agrupado, que almacena el índice y los datos por separado. Los nodos hoja no almacenan datos directamente, solo almacenan la dirección de los datos.
2.
Además de crear índices de clave primaria, MySQL también puede crear otros índices, como índices comunes, índices de clave única, etc. índices y nodos hoja también se almacenan es la dirección de registro.
3.
Para InnoDB, su índice auxiliar y su índice de clave principal son diferentes de MyISAM. El nodo hoja del índice auxiliar de InnoDB no almacena el registro, sino el valor de clave principal correspondiente del registro, y encuentra la clave principal correspondiente. Después del valor, regrese a la tabla de índice de clave principal para consultar de acuerdo con el valor de clave principal hasta que se encuentre el registro completo, por lo tanto, para un índice agrupado como innodb, después de establecer el índice auxiliar, si se busca de acuerdo con el valor de clave del índice auxiliar Luego, después de obtener la clave principal, es necesario volver a consultar la tabla.
4. Operación de índice
1.
El índice de clave principal, la estructura de datos correspondiente al índice único es un árbol B+, y la estructura de datos correspondiente a un índice común es un árbol B.
2.
Las siguientes son algunas instrucciones SQL de uso común cuando se realizan operaciones de índice, como eliminar un índice: alterar tabla nombre_tabla soltar XXX, crear un índice: alterar tabla nombre_tabla agregar índice (nombre_columna), consultar un índice: mostrar índice de nombre_tabla, creando un índice común: crear índice index_name en table_name (column_name)
3.
Además de crear un índice para un campo de una sola columna, también podemos crear un índice para varios campos de columna al mismo tiempo. Dicho índice se denomina índice compuesto. Cuando usamos con frecuencia un campo para encontrar otro campo, puede dar Estos dos campos crean un índice compuesto.
4.
El índice de texto completo requiere que el motor de almacenamiento de la tabla sea MyISAM, y el índice de texto completo predeterminado solo admite inglés, no chino.
En la tabla creada por la siguiente instrucción sql, si desea consultar si hay datos de la base de datos, puede usar seleccionar * de artículos donde el cuerpo es como '%base de datos%', pero este método de consulta no usa el índice de texto completo, que podemos verificar agregando explicación delante de la declaración SQL, seleccione * de los artículos donde coincidan (título, cuerpo) contra ('base de datos')
2. Gestión de transacciones MySQL (énfasis)
1. ¿Qué es una transacción?
1.
Si no se controla el CURD de una tabla, en el caso del envío de declaraciones multicliente y multi-sql, definitivamente ocurrirán varios problemas lógicos. Un boleto se vende dos veces más, por lo que el servidor mysqld es alto cuando se procesa simultáneamente sql Solicitudes de declaraciones de múltiples clientes, si la declaración sql no está controlada, definitivamente ocurrirán varios problemas, porque la operación de cada cliente en el servidor MySQL no es atómica.
2.
Por lo tanto, la operación CURD en la tabla debe satisfacer algunos atributos. Por ejemplo, el proceso de compra de boletos debe ser atómico y los boletos no deben afectarse entre sí. Deben estar aislados. Después de comprar boletos, los datos deben persistir. Finalmente, debe estar en un estado definido, ya sea exitoso o no exitoso, y debe tener la capacidad de retroceder.Por ejemplo, si hay un problema con la base de datos durante la compra del boleto, el servidor está apagado, la base de datos está atacado, etc., la base de datos debe revertir el estado al estado anterior de compra de boletos.
Una transacción se compone de un grupo de declaraciones DML. Varias declaraciones DML son para completar una tarea. Este grupo de declaraciones DML es un todo. O todas se ejecutan con éxito o todas se ejecutan sin éxito. No habrá estado intermedio En MySQL, debe haber más de una transacción en ejecución, por lo que también es necesario controlar múltiples transacciones. Las transacciones no son simplemente una colección de declaraciones DML, sino que también deben cumplir con cuatro atributos.
Atomicidad : todas las operaciones en una transacción se completan o no se completan, y no terminarán en un
determinado enlace en el medio. Si ocurre un error durante la ejecución de la transacción, se retrotraerá (Rollback) al estado anterior al inicio de la transacción, como si la
transacción nunca se hubiera ejecutado. Hay dos formas de reversión: reversión automática y reversión manual. Cuando el servicio MySQL está inactivo, MySQL mismo revertirá automáticamente la mitad de la transacción que se está ejecutando. Aislamiento: la base de datos permite múltiples transacciones simultáneas para leer, escribir y
leer datos al mismo tiempo La capacidad de modificar, el aislamiento puede evitar
la inconsistencia de datos causada por la ejecución cruzada cuando se ejecutan varias transacciones al mismo tiempo. El aislamiento de transacciones se divide en diferentes niveles, que incluyen lectura no confirmada (lectura
no confirmada), lectura confirmada (lectura confirmada), lectura repetible (lectura repetible) y persistencia
serializada (serializable) : después de que finaliza el procesamiento de la transacción, la modificación de los datos es permanente, incluso si el sistema falla, no se perderá De hecho, los datos se colocan en el disco y se conservan.
Coherencia : la integridad de la base de datos no se viola antes de que comience la transacción y después de que finalice. Esto significa que los datos escritos deben cumplir completamente con todas las reglas preestablecidas, incluida la precisión de los datos, la serialidad y la base de datos posterior puede completar espontáneamente el trabajo programado.
Entre las cuatro propiedades anteriores, la coherencia en realidad se realiza mediante las tres primeras propiedades juntas, por lo que siempre que se satisfagan las tres primeras propiedades, se cumple la coherencia de la transacción.
3.
Solo el motor de almacenamiento InnoDB admite transacciones. Las transacciones esencialmente brindan servicios para la capa de aplicación, y la capa de aplicación no se preocupa por los detalles de las implementaciones de transacciones específicas, solo usan transacciones.
4.
En general, hay dos formas de enviar una transacción, el envío automático y el envío manual. De hecho, este método de envío solo afectará el resultado del envío de una sola declaración SQL como una transacción. Verificaremos esta conclusión más adelante.
2. Operaciones comunes de transacciones
1.
La lectura no confirmada es la más baja en el nivel de aislamiento de transacciones Bajo este nivel de aislamiento, es muy conveniente demostrar muchas propiedades de la transacción.
2.
Después de comenzar, la transacción comienza. Las múltiples declaraciones SQL después de comenzar pertenecen a las declaraciones SQL en la transacción. En la transacción, el punto de guardado se puede establecer como el punto de reversión. MySQL admite la reversión direccional y la reversión directa al principio. Si hay es no Si configura el punto de reversión para revertir directamente, se revertirá directamente al principio y la transacción finalizará en este momento, por lo que hay dos formas de finalizar la transacción, una es confirmar y la otra es retroceder directamente al principio En este momento, la transacción finaliza de forma predeterminada, por lo que la operación de reversión es una forma de finalizar la transacción.
3.
Siempre que se confirme la transacción, la operación de la transacción persistirá en el disco y los datos se colocarán en el disco y no se verán afectados por el tiempo de inactividad de la base de datos o el bloqueo del cliente.
Después de comenzar, es decir, después de iniciar una transacción, la transacción se envía manualmente y no se enviará automáticamente, por lo que si la confirmación automática está activada o desactivada no tiene ningún efecto en el método de envío de la transacción después de comenzar.
Una sola declaración será una transacción por defecto en MySQL, y la confirmación automática afecta el método de envío de una sola declaración como una transacción. Por lo general, cuando escribimos una sola declaración SQL en la línea de comando, esta declaración se enviará como una transacción de inmediato, porque el valor predeterminado de confirmación automática es ON está activado, pero si la confirmación automática está desactivada, puede ver que mientras no haya confirmación, el cliente de la derecha no puede ver todas las operaciones de sentencia SQL.
4.
Entonces, la confirmación automática afecta el estado de confirmación de una sola instrucción SQL como una transacción.
3. Nivel de aislamiento de transacciones
1.
El resultado de la ejecución de una transacción se retroalimenta al usuario de forma atómica, es decir, el usuario solo sentirá los cambios de estado antes y después de la ejecución de la transacción, pero cuando se ejecuta la transacción real, debe haber un proceso, por lo que se ejecutan múltiples transacciones, pueden interferir entre sí, por lo que se requiere aislamiento entre transacciones, y el nivel de aislamiento se refleja en el nivel de aislamiento. Por ejemplo, cuando se ejecutan varias transacciones de lectura al mismo tiempo, el nivel de aislamiento se puede reducir al el nivel más bajo, porque se ejecutan varias transacciones de lectura al mismo tiempo, no se afectarán entre sí.
Pero para la lectura y escritura concurrentes, se necesitan otros niveles de aislamiento para controlar la ejecución de múltiples transacciones. De hecho, el escenario de concurrencia más problemático es la lectura y escritura concurrentes, porque leer y leer concurrentes no requiere un alto nivel de aislamiento, solo RU, mientras que la escritura y la escritura simultáneas deben usar el nivel de aislamiento más alto, que solo se puede ejecutar en serie, pero la lectura y la escritura simultáneas son más problemáticas y se pueden usar los niveles RC y RR.
La realización del nivel de aislamiento se realiza principalmente mediante bloqueo, y los diferentes niveles de aislamiento utilizan diferentes bloqueos.
2.
Hay dos formas de establecer el nivel de aislamiento de la transacción. Una es establecer el nivel de aislamiento global y la otra es establecer el nivel de aislamiento de la sesión actual. El nivel de aislamiento de la sesión se puede abreviar como @@tx_isolation, y cada vez que se inicia una nueva sesión de MySQL, el nivel de aislamiento global se utilizará como la configuración de la sesión actual de forma predeterminada.
3.
La lectura no confirmada es el nivel de aislamiento más bajo. Aunque la concurrencia es relativamente alta, casi no hay bloqueo y habrá más problemas al mismo tiempo, como lecturas sucias, lecturas fantasma, lecturas no repetibles y otros problemas concurrentes. Lecturas sucias Es el problema más típico a nivel de RU, la lectura de datos que no han sido comprometidos por una transacción puede afectar fácilmente la toma de decisiones de la capa superior, por lo que este tipo de problemas de concurrencia son intolerables.
4.
El problema de concurrencia más típico en el nivel de aislamiento de lectura y confirmación son las lecturas no repetibles, porque las lecturas repetidas pueden generar resultados diferentes, lo que también afectará la toma de decisiones de nivel superior. La confirmación de lectura significa que la transacción actual puede leer el contenido enviado por otras transacciones, lo que no es un problema en sí mismo, pero el contenido después de que se confirme la transacción A no debería ser visto por otras transacciones que actualmente son simultáneas con la transacción A, y la transacción A debe ejecutarse Después de eso, otras transacciones reiniciadas en este momento pueden ver el contenido después de que se confirme la transacción A, por lo que la confirmación de lectura también tiene sus propios problemas de concurrencia.
5.
El nivel RR, también conocido como nivel de lectura repetible, es el nivel de aislamiento predeterminado de MySQL. Siempre que reinicie el servidor mysqld, el nivel de aislamiento se establecerá en el nivel RR de forma predeterminada.
Bajo MySQL, se puede ver que la terminal B no tiene problemas de concurrencia, pero de hecho, en otras bases de datos, el nivel de aislamiento de transacciones a nivel de RR todavía tiene el problema de lectura fantasma, pero MySQL lo resuelve mediante gap lock + row lock El problema de la lectura fantasma se ha resuelto y algunas otras bases de datos no lo han resuelto.
La lectura fantasma significa que los datos insertados por otras transacciones pueden leerse en caso de lectura repetida, porque el aislamiento se completa al bloquear los datos y los datos insertados en sí no existen, por lo que el método de bloqueo general no puede resolver el problema. problema de lectura, pero MySQL lo resolvió.
Vale la pena señalar que la lectura fantasma se refiere al hecho de que cuando se están insertando otras transacciones, la lectura repetida puede leer la tabla después de insertar los datos, como si hubiera una ilusión. Si otras transacciones actualizan y eliminan datos, la lectura repetida aún puede evitar problemas de concurrencia, porque manipulan los datos existentes.
De hecho, en el nivel RR, ¿por qué la lectura es repetible? Cuando SQL lea por primera vez, agregue directamente un bloqueo de fila a los datos para asegurarse de que otras transacciones no puedan actualizar y eliminar los datos. Al mismo tiempo, agregue un bloqueo de espacio a los datos. Si la tabla tiene un índice, agregue un brecha cerca del registro actual Bloquear para evitar el comportamiento de insertar datos.
6.
El nivel de aislamiento de la serialización es demasiado simple y grosero. Independientemente de la operación que realice la transacción, debe cumplirse estrictamente para ejecutarse de manera serializada. Este tipo de concurrencia es demasiado bajo y la eficiencia es muy lenta. no se puede usar en la práctica. La solución puede causar problemas de tiempo fuera o competencia de bloqueo. Este nivel de aislamiento es demasiado extremo.
7.
En la tabla se puede ver que cuanto mayor sea el nivel de aislamiento, se generarán menos problemas de concurrencia, pero el rendimiento de concurrencia de la base de datos será menor, por lo que a menudo es necesario encontrar un equilibrio entre seguridad y rendimiento. punto de equilibrio Es el nivel de aislamiento de lectura repetible de RR, que también es el nivel de aislamiento predeterminado de la base de datos.
Desde un punto de vista técnico, la tecnología AID logra la consistencia, pero de hecho, la consistencia está fuertemente relacionada con la lógica del usuario. La consistencia no solo debe estar bien respaldada a nivel técnico, sino que también debe ser bien mantenida por los programadores a nivel nivel de lógica de usuario Consistencia de las transacciones de la base de datos.
4. MVCC (mejora el rendimiento de la base de datos al leer y escribir simultáneamente)
1.
El control de concurrencia de múltiples versiones MVCC es un método de control de conflicto de lectura y escritura de alta concurrencia.Al leer y escribir bases de datos simultáneamente, MVCC puede hacerlo sin bloquear la operación de escritura durante la operación de lectura y sin bloquear la operación de lectura durante la escritura Operation. , que mejora en gran medida el rendimiento de las lecturas y escrituras simultáneas de la base de datos.
Además, MVCC también soluciona el problema de lectura fantasma a nivel de RR, así como problemas como lectura sucia y lectura no repetible.
MVCC es una espada afilada para mejorar el rendimiento de la base de datos.
2.
MVCC asigna un Id. de transacción de crecimiento unidireccional a la transacción. Cuando la transacción modifica los datos, guardará una versión y la versión se asocia con el Id. de transacción.
Por lo tanto, cada transacción tiene su propia ID de transacción, y el orden en que llegan las transacciones se puede determinar de acuerdo con el tamaño de la ID de la transacción. Cuanto mayor sea la ID de la transacción, más nueva será la transacción.
mysqld definitivamente se enfrentará a la situación de procesar múltiples transacciones, por lo que mysqld debe administrar múltiples transacciones, es decir, primero describir y luego organizar, para que cada transacción corresponda a un objeto de estructura.
3.
Habrá tres campos de columna ocultos en la tabla implementada por MVCC. DB_TRX_ID se usa para registrar el ID de transacción del registro actual en la tabla de creación, o el ID de transacción de la última modificación del registro actual. El puntero DB_ROLL_PTR apunta al registro anterior de este registro. En la versión histórica, DB_ROW_ID es la clave principal oculta cuando hablamos de índices hace mucho tiempo. Si no hay una clave principal en la tabla, MySQL creará un índice agrupado con DB_ROW_ID como clave valor por defecto, es decir, un árbol B+.
Además de los tres campos de columna ocultos anteriores, también hay un indicador para eliminar el bit.
4.
El registro de deshacer también es un papel importante en la realización de MVCC. Puede entenderse como un búfer para guardar la cadena de versiones de los cambios en el registro de transacciones en la tabla. El aislamiento de transacciones y la implementación de operaciones de reversión son inseparables de el registro de deshacer.
5.
Las adiciones, eliminaciones y modificaciones formarán la versión histórica del registro actual. Select no necesita formar una versión histórica, pero select tiene dos opciones al leer, una es leer el último registro y la otra es leer el versión histórica del registro, es decir, lectura actual y lectura de instantánea.La lectura de instantánea garantiza la seguridad y la concurrencia de lectura y escritura, y no es necesario realizar el bloqueo, porque los datos de lectura de instantánea y adición, eliminación y modificación Las operaciones son diferentes versiones de registros, uno son datos históricos, uno son los datos actuales.
Las versiones históricas en el registro de deshacer se denominan instantáneas una por una. Una vez que se confirma la transacción, estas instantáneas se liberarán, por lo que los registros en el registro de deshacer entran y salen, así que no se preocupe de que se registre el registro de deshacer. Lleno.
Realizar el aislamiento de transacciones requiere no solo los datos de la versión histórica, sino también la vista de lectura. Solo a través de la vista de lectura se puede realizar el aislamiento real de la transacción, es decir, qué información de la versión se debe ver cuando se seleccionan diferentes transacciones para leer.
Vista de lectura La vista de lectura se genera cuando la transacción ejecuta la lectura de instantáneas por primera vez, y la vista de lectura es en realidad un objeto instanciado desde la clase ReadView. Generalmente se denomina instantánea. Hay cuatro variables miembro dentro del objeto de instantánea. muy importante y una implementación técnica importante para lograr el aislamiento de transacciones.
m_ids guarda el ID de transacción que está activo en el sistema cuando se genera la vista de lectura up_limit_id guarda el ID de transacción con el ID de transacción más pequeño
entre m_ids created_trx_id almacena el ID de transacción para crear el registro actual, por lo que ahora tenemos el la vista de lectura en el lado izquierdo, y el DB_TRX_ID de todos los registros en la cadena de versión histórica en el lado derecho, y qué registros de versión deben leerse cuando la transacción actual selecciona leer. De hecho, está determinado por la vista de lectura y el Cadena de versiones históricas.
La siguiente figura ha explicado el algoritmo de visibilidad de transacciones.
Si el ID correspondiente a un registro en la cadena de versión es mayor o igual que el ID límite, significa que la transacción correspondiente a este registro es una nueva transacción después de que se crea la instantánea, entonces la transacción no debería ver este registro. que creó la instantánea.
Si el ID correspondiente a un registro en la cadena de versión es menor que el ID superior o igual a author_trx_id, significa que este registro es una transacción que se envió mucho antes de que se creara la instantánea, o que este registro en sí es un cambio realizado por el transacción que creó la instantánea. Significa que este registro debe ser visto por la empresa actual.
Si el ID correspondiente a un registro en la cadena de versión está en m_ids, significa que la transacción correspondiente al registro aún no se ha enviado. La transacción que crea la vista de lectura no debería ver este registro. Una vez que se ve, es una lectura sucia. Si la ID correspondiente a un determinado registro en la cadena de versiones no está en m_ids y es más pequeña que la ID de límite y más grande que la ID de arriba, significa que la transacción se ha enviado, pero ¿por qué su ID no es más pequeña que la de arriba? ID es en realidad porque la transacción ha llegado El tiempo es relativamente tarde, pero la transacción es corta y se ejecuta muy rápidamente Cuando se forma la instantánea, la transacción ya se ha ejecutado, por lo que dichos registros de versión son visibles.
La siguiente es la estrategia de procesamiento de visibilidad de transacciones correspondiente al código fuente. changes_visible es una función para que MySQL juzgue qué tipo de registros deben verse al leer la instantánea de la transacción actual. trx_id_t es un parámetro pasado desde el exterior. El id de transacción correspondiente a el registro para determinar si el registro debe ser visto por la transacción que llama a la función changes_visible.
Por ejemplo, cuando id<m_up_limit_id o id==m_creator_trx_id, se debe ver el registro actual, por lo tanto, devuelva verdadero, id>=m_low_limit_id, el registro actual no se debe ver, devuelva falso, o si la transacción en m_ids está vacía, en Al mismo tiempo, si el Id es menor que m_low_limit_id, significa que la transacción correspondiente al registro ya se envió y se puede ver.
Si no se cumple ninguna de las condiciones de juicio anteriores, juzgue si el id correspondiente del registro actual está en m_ids, si lo está, no se puede ver, devuelve falso, si no lo está, se puede ver y devuelve verdadero.
Si no se debe ver el registro actual, continúe recorriendo el siguiente registro en la cadena de versiones.
Vale la pena señalar que la vista de lectura se forma cuando se realiza la lectura de instantánea para la primera transacción, y la vista de lectura siempre se utilizará en el nivel de RR durante la ejecución de la transacción.
El siguiente experimento es un caso típico en el que trx_id no está en m_ids, pero también es más pequeño que limit_id y más grande que up_id. Los registros en este caso son visibles y se puede ver la transacción actual.
Por lo tanto, podemos resumir el principio básico de la implementación de MVCC y el principio de la visibilidad de lectura de instantáneas de transacciones. Al asignar la información de la versión histórica correspondiente a cada transacción para agregar, eliminar y modificar registros, al igual que copiar en escritura, siempre que el registro se modifica, la cadena de versión histórica de la transacción se forma en el registro de deshacer y, al mismo tiempo, se asigna una identificación de transacción que aumenta gradualmente a cada transacción de acuerdo con el orden de llegada. Cuando se lee la transacción en la instantánea, se Primero se formará la vista de lectura instantánea y el objeto de vista de lectura Hay cuatro variables miembro importantes dentro, a saber, up_limit_id, low_limit_id, Creator_id y m_ids A través de la comparación entre estos cuatro campos y los registros de la cadena de versión en el registro de deshacer, puede obtenga qué tipo de registros se deben ver en la transacción que crea la vista de lectura.
5. La diferencia esencial entre RR y RC
1.
En MVCC, la lectura de instantáneas no se bloqueará, por lo que la lectura y la escritura no se excluyen mutuamente. Después de que la transacción A realiza una modificación y antes de confirmar, la transacción B forma una instantánea, y el ID de transacción correspondiente al registro modificado está solo en m_ids en la instantánea, entonces la transacción B no debería ver la modificación realizada por la transacción A en el registro. Si desea ver los datos más recientes, puede usar el método de agregar un bloqueo compartido para leer. En este momento, los datos leídos son los más recientes, pero esto no significa que los últimos deban ser correctos. No queremos un Los resultados leídos por la transacción durante la operación son diferentes.
2.
Antes de que se lea la instantánea de la transacción B, la transacción A completa la modificación del registro y lo envía, luego la transacción B debería poder ver la modificación del registro realizada por la transacción A durante todo el período de su propia ejecución, porque la transacción A ha sido enviado, tanto RR como RC deberían verlo.
Desde la perspectiva del principio de implementación de MVCC, puede haber dos situaciones, una es que la ID de la transacción A es menor que up_limit_id o la ID de la transacción no está en m_ids, es decir, la transacción A llega muy temprano y se envía en avanzar, formando La transacción de la instantánea debe verse, o la transacción A llega más tarde que la transacción que forma la instantánea, pero la transacción A es una transacción corta, antes de que la transacción actual forme una instantánea, la transacción A se ejecuta y confirma, luego la instantánea La transacción también debe verse llegar. Entonces, en cualquier caso, la transacción B debería ver los cambios realizados por la transacción A en el registro.
Lo que hay que aprender es que no importa si los datos leídos por la transacción son nuevos o antiguos, ¡lo que importa es que los datos leídos por la transacción durante la ejecución son siempre los mismos!
3.
La diferencia esencial entre RR y RC es la formación de instantáneas. Después de que la transacción en el nivel RR forma una instantánea por primera vez, la instantánea se utilizará durante todo el período de ejecución de las transacciones posteriores. Esta es la razón por la cual el nivel RR es lectura repetible Sí, porque el objeto de vista de lectura permanece sin cambios. Cada vez que una transacción en el nivel RC lee una instantánea, se regenerará una nueva vista de lectura, por lo que en el nivel RC, puede ver el contenido de otras transacciones después del envío, porque el nivel RC generará una nueva vista de lectura y hacer visibles nuevamente los juicios sexuales.
Hablemos de la esencia de la diferencia entre los dos. Cuando la instantánea se lee por primera vez en el nivel RR, se creará un nuevo objeto de vista de lectura, y este objeto de vista de lectura se usará todo el tiempo durante la ejecución de la transacción En el nivel RC, cada instantánea lee En cualquier momento, se creará un nuevo objeto de vista de lectura y el objeto de vista de lectura original se eliminará, por lo que durante la ejecución de la transacción, el objeto de vista de lectura actualizado continuamente es siempre usado
El nivel de RU es siempre la lectura actual, sin control de bloqueo, RR y RC son lecturas instantáneas (MVCC) y la serialización también es la lectura actual, pero está controlada por bloqueos, por lo que la serialización es entre lecturas o lecturas. se requieren entre lectura y escritura, y entre escritura y escritura, por lo que la concurrencia de serialización es baja, porque no importa qué operación esté bloqueada.
3. Características de la vista de MySQL
1.
Las vistas no se usan mucho en la práctica, pero también tenemos un poco de comprensión.
La creación de una vista se crea en función del resultado de la consulta de selección, cree la vista nombre_vista como selección ..., la vista creada es en realidad una tabla, si modifica los datos en la vista, los datos en la tabla original también se modificarán en consecuencia, por lo tanto, en términos generales, las vistas solo se usan para consultar, no para modificar, porque los datos en la tabla base se verán afectados.
Si consulta con frecuencia solo una parte de los datos de la tabla, puede optar por crear una vista para esta parte de los datos y puede consultar directamente desde la vista la próxima vez que consulte.
Cuatro, gestión de usuarios de MySQL
1.
Después de instalar MySQL, habrá una base de datos predeterminada llamada mysql, y habrá una tabla de usuarios dentro de la base de datos, que almacena la información de todos los usuarios bajo el servicio mysqld actual, incluidos muchos campos, los más utilizados. los campos son host, usuario, autenticación_cadena y la contraseña del usuario está encriptada por la función contraseña (), por lo que no podemos entenderla.
2.
Al crear un nuevo usuario, debe especificar el nombre de usuario, el nombre de host y la contraseña que deben autenticarse al iniciar sesión. Después de crear un nuevo usuario, para que el nuevo usuario tenga efecto, es mejor actualice los privilegios de vaciado de permisos.
Al eliminar un usuario, debe especificar el nombre de usuario y el método de inicio de sesión del host.
El usuario raíz puede cambiar las contraseñas de inicio de sesión de todos los usuarios, por lo que al cambiar el secreto, se recomienda usar directamente la identidad del usuario raíz para cambiar las contraseñas de todos los usuarios.
Podemos especificar permisos a los usuarios, como otorgar consultas, agregar, eliminar, modificar y otros permisos para una biblioteca específica, una tabla específica y también se pueden especificar contraseñas al otorgar permisos, pero trate de especificar al crear usuarios Buenas contraseñas, don No especificar contraseñas al habilitar. Los permisos de revocación se pueden revocar mediante el comando revocar.
5. Clientes de API e interfaz gráfica
1.
Además del cliente de línea de comandos que hemos estado usando antes, también podemos usar el lenguaje C para conectarnos a la base de datos y usar la API para acceder al servicio de la base de datos como un cliente.Podemos usar directamente yum install -y mysql-community -Descarga del servidor, generalmente al descargar, el paquete de desarrollo se descargará automáticamente para nosotros. Si no hay un paquete de desarrollo, puede usar yum install -y mysql-devel para descargar manualmente el paquete de desarrollo. Después de descargar e instalar, podemos usar vscode en forma de API Para conectarse y usar la base de datos.
Después de la instalación, habrá archivos de encabezado utilizados por el lenguaje C para conectarse a la base de datos en /usr/include/mysql, y habrá bibliotecas dinámicas y bibliotecas estáticas necesarias para conectarse a la base de datos en /lib64/mysql.
2.
Después de preparar el entorno de desarrollo, intentemos conectarnos a la base de datos.
Utilice el archivo de encabezado mysql.h para especificar la ruta donde el compilador busca el archivo de encabezado. Al vincular la biblioteca, debe especificar la ruta de enlace del vinculador y el nombre de la biblioteca que se vinculará Estos campos deben determinarse en el archivo MAKE.
Antes de vincular la biblioteca, debe llamar a mysql_init para inicializar.mysql_init devolverá algo similar a un descriptor de archivo, y puede usar myfd para operar en la base de datos. Después de la inicialización, llame a mysql_real_connect para conectarse a la base de datos. Al conectarse, debe pasar los parámetros correspondientes, como contraseña, nombre de usuario, método de inicio de sesión, nombre de la base de datos, número de puerto, etc.
mysql_query se usa para emitir comandos MySQL a la base de datos. El primer parámetro es myfd, que es el descriptor del archivo. Cuando el comando emitido es adición, eliminación y modificación, el resultado que devolvemos al cliente solo necesita ser Query OK o Query falló. Esto no es difícil de manejar. Podemos implementar un cliente similar a la línea de comando a través de la API. No es difícil. Solo necesitamos llamar a mysql_query. La dificultad es la declaración de consulta seleccionada, porque la consulta debe devolver los resultados del procesamiento de la fila de comandos, por lo que si desea emitir comandos de consulta, solo mysql_query no es suficiente y necesita la ayuda de otras API.
A continuación, veamos cómo imprimir el resultado devuelto de la consulta sql cuando la declaración emitida es una declaración de consulta.
mysql_store_result pondrá el resultado de ejecución de la declaración en res, solo necesitamos extraer la información de res e imprimirla en la pantalla, mysql_num_rows se usa para obtener el número de filas en el conjunto de resultados, mysql_nums_fields se usa para obtener el número de columnas en el conjunto de resultados, mysql_fetch_fields Usado para obtener el nombre de la columna, el puntero devuelto apuntará a una matriz unidimensional, y el contenido de la matriz unidimensional es el nombre de cada campo de columna. mysql_fetch_row obtiene el contenido del conjunto de resultados, llama a mysql_fetch_row continuamente, saltará automáticamente a la siguiente línea para nosotros como un iterador y devolverá la dirección de la siguiente línea a la línea, para que podamos imprimir el contenido de cada línea en doblar.
mysql_fetch_field no es tan conveniente de usar como mysql_fetch_fields. Este último puede devolver directamente una matriz unidimensional. Podemos atravesar esta matriz y mostrar el contenido de la matriz, lo cual es más conveniente.
La siguiente es la implementación del código específico. No olvide cerrar la conexión mysql y liberar el conjunto de resultados res. res se aplica dinámicamente, por lo que también debe liberarse.
El siguiente es el resultado después de ejecutar la declaración de consulta
3.
Solo se puede decir que MySQL Workbench está bien para usar, y se siente mejor escribir directamente la línea de comando, pero debemos usar la interfaz gráfica para acceder al servicio de la base de datos en el trabajo real. El costo de uso también es relativamente bajo, puede descargar uno y jugar con él usted mismo
