Capítulo 04_Arquitectura lógica

1. Análisis de arquitectura lógica.

1.1 El servidor procesa las solicitudes de los clientes.

Entonces, ¿qué hace el proceso del servidor con la solicitud enviada por el proceso del cliente para producir el resultado final del procesamiento? Aquí la solicitud de consulta es

Visualización de ejemplo:

Insertar descripción de la imagen aquí

Veámoslo más de cerca:

Insertar descripción de la imagen aquí

1.2 Conectores

1.3 Capa 1: Capa de conexión

Antes de que el sistema (cliente) acceda al servidor MySQL, lo primero que hace es establecer una conexión TCP.

Después de que el protocolo de enlace de tres vías establece la conexión con éxito, el servidor MySQL realiza la autenticación de identidad y la adquisición de autoridad en la contraseña de la cuenta transmitida por TCP.

Si el nombre de usuario o la contraseña son incorrectos, recibirá un Acceso denegado por error de usuario y el programa cliente finalizará la ejecución.
Después de pasar la autenticación del nombre de usuario y la contraseña, los permisos que pertenecen a la cuenta y la conexión se encontrarán en la tabla de permisos. La lógica de juicio de permisos posterior dependerá
de los permisos leídos en este momento.

Una vez que la conexión TCP recibe la solicitud, se debe asignar a un hilo específicamente para interactuar con este cliente. Por lo que habrá un grupo de subprocesos para llevar a cabo los
procesos posteriores. Cada conexión obtiene un subproceso del grupo de subprocesos, lo que elimina la sobrecarga de crear y destruir subprocesos.

1.4 Capa 2: Capa de Servicio

Interfaz SQL: interfaz SQL
- Reciba el comando SQL del usuario y devuelva los resultados que el usuario necesita consultar. Por ejemplo, SELECT... FROM es para llamar a
  la interfaz SQL
- MySQL admite múltiples interfaces de lenguaje SQL, como DML (lenguaje de manipulación de datos), DDL (lenguaje de definición de datos), procedimientos almacenados, vistas, activadores y funciones personalizadas .
Analizador: analizador
- Realice análisis de sintaxis y análisis semántico de declaraciones SQL en el analizador. Descomponga la declaración SQL en una estructura de datos y
  pase esta estructura a los pasos posteriores. La entrega y el procesamiento posteriores de la declaración SQL se basan en esta estructura. Si se encuentra un error durante la descomposición
  , significa que la declaración SQL no es razonable.
- Cuando el comando SQL se pasa al analizador, el analizador lo verificará y analizará, y se creará un árbol de sintaxis para él. El árbol de sintaxis de
  consulta se enriquecerá según el diccionario de datos y se verificará si el cliente tiene la autoridad para ejecutar la consulta. Después de crear el árbol de sintaxis, MySQL
  también optimizará la sintaxis de la consulta SQl y reescribirá la consulta.
Optimizador: optimizador de consultas
- Después de analizar la sintaxis de la declaración SQL y antes de la consulta, el optimizador de consultas se utiliza para determinar la ruta de ejecución de la declaración SQL y generar un plan de ejecución.
- Este plan de ejecución indica qué índices se deben utilizar para la consulta (recuperación de tabla completa o recuperación de índice), cuál es el orden de las conexiones entre tablas y, finalmente, se llamará al método proporcionado por el motor de almacenamiento de acuerdo con los pasos del plan de ejecución para realmente ejecuta la consulta y los resultados de la consulta se devuelven al usuario.
- Utiliza una estrategia de "seleccionar-unir-proyecto" para realizar consultas. Por ejemplo:

这个SELECT查询先根据WHERE语句进行选取，而不是将表全部查询出来以后再进行gender过
滤。 这个SELECT查询先根据id和name进行属性投影，而不是将属性全部取出以后再进行过
滤，将这两个查询条件连接起来生成最终查询结果。
Caches & Buffers： 查询缓存组件
MySQL内部维持着一些Cache和Buffer，比如Query Cache用来缓存一条SELECT语句的执行结
果，如果能够在其中找到对应的查询结果，那么就不必再进行查询解析、优化和执行的整个过
程了，直接将结果反馈给客户端。
这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等 。
这个查询缓存可以在不同客户端之间共享。
从MySQL 5.7.20开始，不推荐使用查询缓存，并在MySQL 8.0中删除。

1. 5 Capa 3: Capa del motor

La capa del motor de almacenamiento enchufable (motores de almacenamiento) es realmente responsable del almacenamiento y la recuperación de datos en MySQL y
realiza operaciones en los datos subyacentes mantenidos en el nivel del servidor físico.El servidor se comunica con el motor de almacenamiento a través de API. Los diferentes motores de almacenamiento tienen diferentes funciones, por lo que
podemos elegir según nuestras necesidades reales.

Los motores de almacenamiento soportados por MySQL 8.0.25 de forma predeterminada son los siguientes:

1. 6 capas de almacenamiento

Todos los datos, las definiciones de bases de datos y tablas, el contenido de cada fila de la tabla y los índices se almacenan en el sistema de archivos y se almacenan en forma de archivos.

y completar la interacción con el motor de almacenamiento. Por supuesto, algunos motores de almacenamiento, como InnoDB, también admiten la gestión directa de dispositivos sin formato sin utilizar un sistema de archivos
, pero la implementación de sistemas de archivos modernos hace que esto sea innecesario. En el sistema de archivos, puede utilizar discos locales y
varios sistemas de almacenamiento como DAS, NAS y SAN.

SELECT id,name FROM student WHERE gender = '女';

小故事：
如果我问你9+8×16-3×2×17的值是多少，你可能会用计算器去算一下，最终结果 35 。如果再问你一遍9+8×16-
3×2×17的值是多少，你还用再傻呵呵的再算一遍吗？我们刚刚已经算过了，直接说答案就好了。

1.7 Resumen

El diagrama de la arquitectura MySQL se muestra al principio de esta sección. Para facilitar la familiaridad con el proceso de ejecución de SQL, podemos simplificarlo de la siguiente manera:

Simplificado en una estructura de tres capas:

1. Capa de conexión: el cliente y el servidor establecen una conexión y el cliente envía SQL al servidor;

2. Capa SQL (capa de servicio): realiza el procesamiento de consultas en declaraciones SQL, no tiene nada que ver con el método de almacenamiento de los archivos de la base de datos;

3. Capa del motor de almacenamiento: se ocupa de los archivos de la base de datos y es responsable del almacenamiento y la lectura de datos.

2. Proceso de ejecución de SQL

2. 1 proceso de ejecución de SQL en MySQL

Proceso de consulta MySQL:

1. Caché de consultas : si el servidor encuentra esta declaración SQL en el caché de consultas, devolverá el resultado directamente al cliente; de lo contrario
, ingresará a la etapa del analizador. Cabe señalar que debido a que el almacenamiento en caché de consultas suele ser ineficiente,
esta función se abandonó después de MySQL8.0.

El almacenamiento en caché de consultas es inútil en la mayoría de los casos. ¿Por qué?

El almacenamiento en caché de consultas almacena en caché los resultados de las consultas por adelantado para que pueda obtenerlos directamente sin ejecutarlos la próxima vez. Cabe señalar que en

El caché de consultas en MySQL no almacena en caché el plan de consulta, sino los resultados correspondientes de la consulta. Esto significa que la solidez de la coincidencia de consultas se reduce considerablemente
y solo la misma operación de consulta llegará al caché de consultas. Cualquier diferencia en caracteres entre las dos solicitudes de consulta (por ejemplo: espacios, comentarios, mayúsculas y
minúsculas) hará que se pierda el caché. Por lo tanto, la tasa de aciertos de la caché de consultas de MySQL no es alta.

Al mismo tiempo, si la solicitud de consulta contiene ciertas funciones del sistema, variables y funciones definidas por el usuario y algunas tablas del sistema, como
tablas en las bases de datos mysql, information_schema y performance_schema, la solicitud no se almacenará en caché. Tomando algunas funciones del sistema
como ejemplo, dos llamadas de la misma función pueden producir resultados diferentes. Por ejemplo, la función AHORA producirá la última
hora actual cada vez que se llame. Si se llama a esta función en una solicitud de consulta, incluso si el consulta La información de texto solicitada es la misma, por lo que dos consultas en diferentes momentos también deberían obtener resultados diferentes. Si se almacena en caché en la primera consulta, será incorrecto
utilizar directamente los resultados de la primera consulta en la segunda consulta.

Además, dado que es un caché, habrá un momento en que su caché dejará de ser válido. El sistema de caché de MySQL monitoreará cada tabla involucrada. Siempre que
se modifique la estructura o los datos de la tabla, si
se usan las instrucciones INSERT, UPDATE, DELETE, TRUNCATE TABLE, ALTER TABLE, DROP TABLE o DROP DATABASE en la tabla, use All ¡Las consultas almacenadas en caché para esta tabla dejarán de ser válidas y
se eliminarán de la caché! Para bases de datos con una gran presión de actualización, la tasa de aciertos de la caché de consultas será muy baja.

2. Analizador : realice análisis de sintaxis y análisis semántico de declaraciones SQL en el analizador.

El analizador primero hace un "análisis léxico". Lo que ingresa es una declaración SQL compuesta de múltiples cadenas y espacios. MySQL necesita identificar
cuáles son las cadenas que contiene y qué representan. MySQL reconoce por la palabra clave "select" que ingresó que se trata de una declaración de consulta
. También necesita reconocer la cadena "T" como "nombre de tabla T" y la cadena "ID" como "ID de columna".

SELECT employee_id,last_name FROM employees WHERE employee_id = 101;

接着，要做“语法分析”。根据词法分析的结果，语法分析器（比如：Bison）会根据语法规则，判断你输
入的这个 SQL 语句是否满足 MySQL 语法。

select department_id,job_id,avg(salary) from employees group by department_id;

如果SQL语句正确，则会生成一个这样的语法树：

En el optimizador de consultas, se puede dividir en etapa de optimización de consultas lógicas y etapa de optimización de consultas físicas.

4. Actuador:

Hasta ahora no se ha leído ni escrito ninguna tabla real, sólo se ha elaborado un plan de ejecución. Entonces entramos en la etapa de ejecutor.

select * from test 1 join test 2 using(ID)
where test 1 .name='zhangwei' and test 2 .name='mysql高级课程';

方案 1 ：可以先从表 test 1 里面取出 name='zhangwei'的记录的 ID 值，再根据 ID 值关联到表 test 2 ，再判
断 test 2 里面 name的值是否等于 'mysql高级课程'。
方案 2 ：可以先从表 test 2 里面取出 name='mysql高级课程' 的记录的 ID 值，再根据 ID 值关联到 test 1 ，
再判断 test 1 里面 name的值是否等于 zhangwei。

这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。优化
器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。

如果你还有一些疑问，比如优化器是怎么选择索引的，有没有可能选择错等。后面讲到索引我们再谈。

Los siguientes son los pasos del proceso de análisis léxico Sql:

3. Optimizador: el optimizador determinará la ruta de ejecución de la declaración SQL, por ejemplo, si se basa en la recuperación completa de la tabla o en la recuperación del índice.

Ejemplo: la siguiente declaración ejecuta una unión entre dos tablas:

Es necesario determinar si el usuario tiene permiso antes de la ejecución. De lo contrario, se devolverá un error de permiso. Si tiene permiso, ejecute SQL

Consulta y devolución de resultados. En versiones inferiores a MySQL 8.0, si se configura el caché de consultas, los resultados de la consulta se almacenarán en caché.

Por ejemplo: en la prueba de la tabla, el campo ID no tiene índice, entonces el proceso de ejecución del ejecutor es el siguiente:

En este punto, se completa la ejecución de esta declaración. Para tablas con índices, la lógica de ejecución es similar.

El flujo de declaraciones SQL en MySQL es: declaración SQL → caché de consultas → analizador → optimizador → ejecutor.

select * from test where id= 1 ;

调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 1 ，如果不是则跳过，如果是则将这行存在结果集中；
调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。

执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

2. 2 Principio de ejecución de SQL en MySQL 8

1. Confirme si la creación de perfiles está activada

profiling=0 significa cerrado, necesitamos activar el perfilado, es decir, establecerlo en 1:

2. Ejecute la misma consulta SQL varias veces.

Luego ejecutamos una consulta SQL (puede ejecutar cualquier consulta SQL):

3. Ver perfiles

Ver todos los perfiles generados por la sesión actual:

mysql> select @@profiling;

mysql> show variables like 'profiling';

mysql> set profiling= 1 ;

mysql> select * from employees;

mysql> show profiles;  # 显示最近的几次查询

4. Ver perfil

Muestre el plan de ejecución y vea los pasos de ejecución del programa:

Por supuesto, también puede consultar el ID de consulta especificado, como por ejemplo:

Los resultados del tiempo de ejecución de la consulta SQL son los mismos que los anteriores.

Además, también puedes consultar contenido más rico:

continuar:

mysql> show profile;

mysql> show profile for query 7 ;

mysql> show profile cpu,block io for query 6 ;

mysql> show profile cpu,block io for query 7 ;

2.3 Principio de ejecución de SQL en MySQL 5.7

La operación anterior se probó en MySQL5.7 y se descubrió que el proceso de consulta ejecutado por la misma declaración SQL dos veces antes y después sigue siendo el mismo. ¿No usa
caché? Aquí necesitamos habilitar explícitamente el modo de caché de consultas. Establezca lo siguiente en MySQL5.7:

1. Habilite el almacenamiento en caché de consultas en el archivo de configuración.

Agregue una nueva línea en /etc/my.cnf:

2. Reinicie el servicio mysql.

3. Habilite el plan de ejecución de consultas

Dado que el servicio se reinició, debe volver a ejecutar las siguientes instrucciones para habilitar la creación de perfiles.

4. Ejecute la declaración dos veces:

5. Ver perfiles

query_cache_type= 1

systemctl restart mysqld

mysql> set profiling= 1 ;

mysql> select * from locations;

mysql> select * from locations;

6. Ver perfil

Muestre el plan de ejecución y vea los pasos de ejecución del programa:

mysql> show profile for query 1 ;

mysql> show profile for query 2 ;

La conclusión es evidente. Al ejecutar el número 2, hay mucha menos información que al ejecutar el número 1. Se puede ver en la captura de pantalla que la declaración de consulta se lee directamente desde el caché.

recuperar datos.

2.4 Orden de sintaxis SQL

A medida que se actualiza la versión de MySQL, su optimizador también se actualiza constantemente, el optimizador analizará los diferentes consumos de rendimiento causados por diferentes secuencias de ejecución
y ajustará dinámicamente la secuencia de ejecución.

Requisito: Consultar el número de personas mayores de 20 años en cada departamento, y el número de personas mayores de 20 años no puede ser menor a 2, y mostrar la información del departamento con mayor número de personas.

La siguiente es una secuencia de consultas que ocurre con frecuencia:

2.5 Proceso de ejecución de SQL en Oracle (comprensión)

Oracle utiliza un grupo compartido para determinar si una declaración SQL tiene un caché y un plan de ejecución. A través de este paso, podemos saber si se
debe utilizar un análisis duro o un análisis suave.

Primero echemos un vistazo al proceso de ejecución de SQL en Oracle:

Como se puede ver en la imagen de arriba, la declaración SQL ha pasado por los siguientes pasos en Oracle.

1. Revisión gramatical: verifique si la ortografía de SQL es correcta. Si es incorrecta, Oracle informará un error de sintaxis.

2. Verificación semántica: verifique si el objeto de acceso en SQL existe. Por ejemplo, cuando escribimos una instrucción SELECT, si el nombre de la columna se escribe incorrectamente, el sistema
generará un error. La función de la verificación de sintaxis y la verificación semántica es garantizar que la declaración SQL esté libre de errores.

3. Verificación de permisos: verifique si el usuario tiene permiso para acceder a los datos.

4. Verificación del grupo compartido: el grupo compartido (Shared Pool) es un grupo de memoria cuya función principal es almacenar en caché las declaraciones SQL y el plan de ejecución de las declaraciones
. Oracle determina si realizar un análisis suave o duro verificando si el plan de ejecución de la declaración SQL existe en el grupo compartido.
Entonces, ¿ cómo entender el análisis suave y el análisis duro?

En el grupo compartido, Oracle primero realiza una operación hash en la declaración SQL y luego
busca en el caché de la biblioteca (Library Cache) de acuerdo con el valor hash. Si hay un plan de ejecución para la declaración SQL, se usa directamente para la ejecución y Ingrese directamente al enlace "ejecutor", esto es un análisis suave.

Si no se encuentran la declaración SQL y el plan de ejecución, Oracle necesita crear un árbol de análisis para el análisis, generar un plan de ejecución e ingresar al
paso "optimizador", que es un análisis completo.

5. 优化器：优化器中就是要进行硬解析，也就是决定怎么做，比如创建解析树，生成执行计划。
6. 执行器：当有了解析树和执行计划之后，就知道了 SQL 该怎么被执行，这样就可以在执行器中执
行语句了。

Grupo compartido es un término en Oracle que incluye caché de biblioteca, búfer de diccionario de datos, etc. Ya hemos hablado anteriormente sobre el área de caché de la biblioteca, que principalmente
almacena en caché declaraciones SQL y planes de ejecución. El búfer del diccionario de datos almacena definiciones de objetos en Oracle, como tablas, vistas, índices y otros objetos
. Al analizar la declaración SQL, si se necesitan datos relevantes, se extraerán del búfer del diccionario de datos.

El paso de caché de la biblioteca determina si la declaración SQL necesita un análisis completo. Para mejorar la eficiencia de ejecución de SQL, debemos intentar
evitar el análisis exhaustivo, porque durante la ejecución de SQL, la creación de árboles de análisis y la generación de planes de ejecución consumen muchos recursos.

Quizás se pregunte, ¿cómo evitar el análisis duro y utilizar el análisis suave tanto como sea posible? En Oracle, las variables de vinculación son una característica importante. Vincular variables
consiste en utilizar variables en declaraciones SQL para cambiar los resultados de la ejecución de SQL a través de diferentes valores de variables. La ventaja de esto es que puede aumentar
la posibilidad de análisis suave, pero la desventaja es que es posible que el plan de ejecución generado no esté lo suficientemente optimizado, por lo que la necesidad de vincular variables depende de la situación
.

Por ejemplo, podemos utilizar la siguiente declaración de consulta:

También puedes usar variables de enlace como:

La eficiencia de estas dos declaraciones de consulta es completamente diferente en Oracle. Si consulta player_id = 10001 y luego consulta
datos como 10002 y 10003, cada consulta creará una nueva resolución de consulta. El segundo método utiliza variables de vinculación
, por lo que después de la primera consulta, habrá un plan de ejecución para este tipo de consulta en el grupo compartido, que es un análisis suave.

Por lo tanto, podemos reducir el análisis duro y reducir la carga de trabajo de análisis de Oracle mediante el uso de variables de enlace. Sin embargo, este método también tiene desventajas:
cuando se utiliza SQL dinámico, diferentes parámetros conducirán a una eficiencia de ejecución de SQL diferente y la optimización de SQL será más difícil.

Diagrama de arquitectura de Oracle:

SQL> select * from player where player_id = 10001 ;

SQL> select * from player where player_id = :player_id;

Diagrama simplificado:

resumen:

Oracle y MySQL tienen diferencias de implementación de software en consultas SQL. Oracle propuso el concepto de grupo compartido, que se utiliza para
determinar si se realiza un análisis suave o duro.

3. Grupo de búfer de base de datos (grupo de búfer)

Después de comprender la función del grupo de búfer, también debemos comprender otra característica del grupo de búfer: la lectura anticipada.

La función del grupo de búfer es mejorar la eficiencia de E / S. Existe un "principio de localidad" cuando leemos datos, lo que significa que usamos algunos datos.

Según los datos, existe una alta probabilidad de que se utilicen algunos datos a su alrededor, por lo que se utiliza el mecanismo de "lectura previa" para cargarlos por adelantado, lo que puede reducir posibles operaciones futuras de E/O del disco.

InnoDB存储引擎是以页为单位来管理存储空间的，我们进行的增删改查操作其实本质上都是在访问页
面（包括读页面、写页面、创建新页面等操作）。而磁盘 I/O 需要消耗的时间很多，而在内存中进行操
作，效率则会高很多，为了能让数据表或者索引中的数据随时被我们所用，DBMS 会申请占用内存来作为
数据缓冲池，在真正访问页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool之后才可以访
问。

这样做的好处是可以让磁盘活动最小化，从而减少与磁盘直接进行 I/O 的时间。要知道，这种策略对提
升 SQL 语句的查询性能来说至关重要。如果索引的数据在缓冲池里，那么访问的成本就会降低很多。

3.1 Grupo de búfer frente a caché de consultas

¿Los grupos de búfer y la caché de consultas son lo mismo? No.

1. Grupo de búfer

首先我们需要了解在 InnoDB 存储引擎中，缓冲池都包括了哪些。

在 InnoDB 存储引擎中有一部分数据会放到内存中，缓冲池则占了这部分内存的大部分，它用来存储各种
数据的缓存，如下图所示：

从图中，你能看到 InnoDB 缓冲池包括了数据页、索引页、插入缓冲、锁信息、自适应 Hash 和数据字典
信息等。
缓存池的重要性：

缓存原则：

“位置 * 频次”这个原则，可以帮我们对 I/O 访问效率进行优化。

首先，位置决定效率，提供缓冲池就是为了在内存中可以直接访问数据。

其次，频次决定优先级顺序。因为缓冲池的大小是有限的，比如磁盘有 200 G，但是内存只有 16 G，缓冲
池大小只有 1 G，就无法将所有数据都加载到缓冲池里，这时就涉及到优先级顺序，会优先对使用频次高
的热数据进行加载。

缓冲池的预读特性：

Después de comprender la función del grupo de búfer, también debemos comprender otra característica del grupo de búfer: la lectura anticipada.

La función del grupo de búfer es mejorar la eficiencia de E / S. Existe un "principio de localidad" cuando leemos datos, lo que significa que usamos

Después de usar algunos datos, existe una alta probabilidad de que también se usen algunos datos a su alrededor, por lo que usar el mecanismo de "lectura previa" para cargar con anticipación puede reducir el futuro.

Posibles operaciones de disco I/О.

2. Consultar caché

Entonces, ¿qué es el caché de consultas?

El almacenamiento en caché de consultas almacena en caché los resultados de las consultas por adelantado para que pueda obtenerlos directamente sin ejecutarlos la próxima vez. Cabe señalar que en

El caché de consultas en MySQL no almacena en caché el plan de consulta, sino los resultados correspondientes de la consulta. Debido a que las condiciones de acierto son estrictas y mientras la tabla de datos
cambie, el caché de consultas dejará de ser válido, por lo que la tasa de aciertos es baja.

3.2 ¿Cómo lee los datos el grupo de búfer?

El administrador del grupo de búfer hará todo lo posible para guardar los datos de uso frecuente. Cuando la base de datos lee una página, primero determinará la página.

Ya sea en el grupo de búfer, si existe, se leerá directamente, si no existe, la página se almacenará en el grupo de búfer a través de la memoria o el disco y luego se procesará.

fila leída.

La estructura y función del caché en la base de datos se muestran en la siguiente figura:

Si actualizamos los datos en el grupo de caché al ejecutar una declaración SQL, ¿los datos se sincronizarán con el disco inmediatamente?

3. 3 Ver/establecer el tamaño del grupo de buffer

Si está utilizando el motor de almacenamiento InnoDB, puede verificar el tamaño del grupo de búfer mirando la variable innodb_buffer_pool_size
. El comando es el siguiente:

Puede ver que el tamaño del grupo de búfer de InnoDB en este momento es solo 134217728/1024/1024 = 128 MB. Podemos modificar el tamaño del grupo de buffer, por ejemplo
a 256 MB, de la siguiente manera:

show variables like 'innodb_buffer_pool_size';

set global innodb_buffer_pool_size = 268435456 ;

o:

Luego, observe el tamaño del grupo de búfer modificado, que se modificó con éxito a 256 MB:

3.4 Múltiples instancias de Buffer Pool

Esto indica que queremos crear 2 instancias de Buffer Pool.

Veamos cómo verificar la cantidad de grupos de buffers, usando el comando:

Entonces, ¿cuánto espacio de memoria ocupa realmente cada instancia de Buffer Pool? De hecho, se calcula mediante esta fórmula:

Es decir, el tamaño total se divide por el número de instancias y el resultado es el tamaño ocupado por cada instancia del Buffer Pool.

3.5 Preguntas extendidas

El Buffer Pool es un componente central de la estructura de memoria de MySQL. Primero puedes imaginarlo como una caja negra.

Actualizar proceso de datos bajo cuadro negro

[server]
innodb_buffer_pool_size = 268435456

[server]
innodb_buffer_pool_instances = 2

show variables like 'innodb_buffer_pool_instances';

innodb_buffer_pool_size/innodb_buffer_pool_instances

De repente se produjo un error mientras estaba actualizando. Quiero volver a la versión anterior a la actualización. ¿Qué debo hacer? Garantía de persistencia de datos y recuperación de transacciones.

¿Cómo podemos hablar de recuperación de fallos si ni siquiera podemos hacerlo?

Respuesta: Rehacer registro y deshacer registro