https://blog.csdn.net/weixin_40009393/article/details/111103350
La arquitectura en capas del sistema de aplicación, con el fin de acelerar el acceso a los datos, almacenará los datos a los que se accede con más frecuencia en la caché para evitar acceder a la base de datos cada vez.
El sistema operativo tendrá un mecanismo de grupo de búfer para evitar el acceso al disco cada vez para acelerar el acceso a los datos.
Como sistema de almacenamiento, MySQL también tiene un mecanismo de grupo de búfer para evitar E / S del disco cada vez que se consultan datos.
Hoy, les hablaré sobre el grupo de búferes de InnoDB.
¿Qué caché del grupo de búfer de InnoDB? ¿Cuál es el uso?
Almacene en caché los datos de la tabla y los datos de índice, cargue los datos del disco en el grupo de búfer, evite la E / S de disco para cada acceso y desempeñe un papel en la aceleración del acceso.
La velocidad es rápida, entonces, ¿ por qué no poner todos los datos en el grupo de búferes ?
Todo tiene dos caras. Independientemente de la volatilidad de los datos, lo opuesto al acceso rápido es la pequeña capacidad de almacenamiento:
(1) El acceso a la caché es rápido, pero la capacidad es pequeña. La base de datos almacena datos de 200G y la capacidad de la caché solo puede ser de 64G;
(2) El acceso a la memoria es rápido, pero la capacidad es pequeña. Si compra un disco portátil con 2T, es posible que la memoria solo sea de 16G;
Por lo tanto, solo los datos "más calientes" se pueden colocar en el lugar "reciente" para reducir el acceso al disco al nivel "máximo".
¿Cómo administrar y eliminar el grupo de búferes para maximizar el rendimiento?
Antes de introducir los detalles específicos, introduzcamos el concepto de "lectura previa".
¿Qué es la lectura previa?
La lectura y escritura en disco no se lee bajo demanda, sino que se lee por página. Se lee al menos una página de datos (generalmente 4K) a la vez. Si los datos que se leerán en el futuro están en la página, la E / S de disco posterior se puede omitido, mejorar la eficiencia.
¿Por qué es eficaz la lectura previa?
El acceso a los datos generalmente sigue el principio de "lectura y escritura centralizada". Si se utilizan algunos datos, los datos cercanos se usarán con una alta probabilidad. Este es el llamado "principio de localidad", que muestra que la carga temprana es efectiva y puede de hecho, reduzca la E / S del disco.
¿Cuál es la relación entre la lectura página por página (4K) y el diseño del grupo de búfer de InnoDB?
(1) La lectura del acceso al disco por página puede mejorar el rendimiento, por lo que el grupo de búfer generalmente almacena en caché los datos por página;
(2) El mecanismo de lectura anticipada nos ha inspirado a agregar algunas páginas a las que "se puede acceder" al grupo de búfer de antemano para evitar futuras operaciones de E / S de disco;
¿Qué algoritmo utiliza InnoDB para administrar estas páginas de búfer?
Lo más fácil de pensar es LRU (el menos utilizado recientemente).
Voz en off: Memcache y OS usarán LRU para la administración de reemplazo de páginas, pero la jugabilidad de MySQL es diferente.
¿Cómo gestiona la LRU tradicional las páginas de búfer?
La forma más común de jugar es colocar las páginas en el grupo de búfer al comienzo de la LRU como el elemento al que se accedió más recientemente, y así ser eliminado a más tardar. Hay dos situaciones:
(1) La página ya está en el grupo de búfer , entonces solo se realiza la acción de "moverse a" el encabezado LRU y no se elimina ninguna página;
(2) Si la página no está en la reserva de búfer , además de la acción de "poner" el encabezado de la LRU, también se requiere la acción de "eliminar" la página de cola de la LRU;
Como se muestra en la figura anterior, si la longitud de LRU del grupo de búfer de administración es 10, las páginas con números de página 1, 3, 5 ..., 40, 7 se almacenan en búfer.
Supongamos que los datos a los que se accederá a continuación se encuentran en la página con el número de página 4:
(1) La página con la página número 4 se encuentra originalmente en el grupo de almacenamientos intermedios;
(2) Coloque la página con la página número 4 al comienzo de la LRU, y no se eliminará ninguna página;
Voz en off: para reducir el movimiento de datos, LRU generalmente se implementa con una lista vinculada.
Supongamos que los datos a los que se accederá a continuación se encuentran en la página con el número de página 50:
(1) La página con la página número 50 no estaba originalmente en el grupo de almacenamientos intermedios;
(2) Coloque la página con la página número 50 al principio del LRU y elimine la página con la página número 7 al final al mismo tiempo;
El algoritmo tradicional del grupo de búfer LRU es muy intuitivo . Se utilizan muchos software, como OS y Memcache. ¿Por qué MySQL es tan hipócrita que no se puede usar directamente?
Hay dos problemas aquí:
(1) La lectura previa falla;
(2) Contaminación de la piscina de amortiguamiento;
¿Qué es el error de lectura anticipada?
Debido a Read-Ahead, la página se coloca en el búfer de antemano, pero al final MySQL no lee los datos de la página, lo que se denomina error de lectura anticipada.
¿Cómo optimizar el error de lectura anticipada?
Para optimizar el error de lectura anticipada, la idea es:
(1) Deje que las páginas que no se puedan leer con anticipación permanezcan en la LRU del grupo de búferes lo más cortas posible;
(2) Deje que las páginas que se leen realmente se muevan al encabezado del grupo de búfer LRU;
Para garantizar que los datos activos que se leen realmente permanezcan en el grupo de búferes el mayor tiempo posible.
El método específico es:
(1) Divida LRU en dos partes:
- La nueva generación (nueva sublista)
- Sublista antigua
(2) Las nuevas y viejas generaciones están conectadas al final, es decir, la cola de la nueva generación está conectada a la cabeza de la vieja generación;
(3) Cuando se agregan páginas nuevas (como páginas leídas previamente) al grupo de búfer, solo se agregan al encabezado de la generación anterior:
- Si los datos se leen realmente (la lectura previa es exitosa), se agregarán al encabezado de la nueva generación
- Si los datos no se leen, se eliminarán del grupo de búferes antes que las "páginas de datos calientes" de la nueva generación.
Por ejemplo, toda la LRU del grupo de búferes es como se muestra arriba:
(1) La longitud de todo el LRU es 10;
(2) El primer 70% son la nueva generación;
(3) El último 30% son la generación anterior;
(4) Las viejas y las nuevas generaciones están conectadas de un extremo a otro;
Si una nueva página con la página número 50 se lee previamente y se agrega al grupo de búferes:
(1) Solo se insertarán 50 del encabezado de la generación anterior, y se eliminarán las páginas al final de la generación anterior (también la cola general);
(2) Suponiendo que la página 50 no se leerá realmente, es decir, la lectura previa falla, se eliminará del grupo de búfer antes de la nueva generación de datos;
Si la página 50 se lee inmediatamente, por ejemplo, SQL accede a los datos de la fila en la página:
(1) Se agregará inmediatamente a la cabeza de la nueva generación;
(2) Las páginas de la nueva generación se incluirán en la generación anterior, y ninguna página se eliminará realmente en este momento;
El grupo de búfer mejorado LRU puede resolver el problema del "error de lectura anticipada".
Voz en off: Pero no dejes de comer por atragantamiento y canceles la estrategia de prelectura porque temes fallar en la prelectura, en la mayoría de los casos el principio de localidad es válido y la prelectura es efectiva.
Las nuevas y antiguas generaciones de LRU mejoradas todavía no pueden resolver el problema de la contaminación de la reserva de amortiguación.
¿Qué es la contaminación del grupo de búfer de MySQL?
Cuando una determinada instrucción SQL necesita escanear una gran cantidad de datos en lotes, puede hacer que se reemplacen todas las páginas del grupo de búfer, lo que hace que se intercambie una gran cantidad de datos activos y el rendimiento de MySQL disminuya drásticamente. Esta situación es llamada contaminación de la piscina de amortiguamiento.
Por ejemplo, si hay una tabla de usuario con una gran cantidad de datos, al ejecutar:
seleccione * del usuario con un nombre como "% shenjian%";
Aunque el conjunto de resultados puede tener solo una pequeña cantidad de datos, este tipo de me gusta no puede llegar al índice. Se requiere un escaneo completo de la tabla y se debe acceder a una gran cantidad de páginas:
(1) Agregue la página al grupo de búfer (inserte el encabezado de la generación anterior);
(2) Lea la fila relacionada de la página (inserte el encabezado de la nueva generación);
(3) El campo de nombre en la fila se compara con la cadena shenjian y, si cumple las condiciones, se agrega al conjunto de resultados;
(4) ... hasta que se escaneen todas las filas de todas las páginas ...
De esta manera, todas las páginas de datos se cargarán en el cabezal de la nueva generación, pero solo se accederá una vez, y los datos calientes reales se intercambiarán en grandes cantidades.
¿Qué tal este tipo de problema de contaminación de la reserva intermedia causado por el escaneo de una gran cantidad de datos?
El grupo de búfer de MySQL ha agregado un mecanismo de "la ventana de tiempo de residencia de la generación anterior":
(1) Suponga que T = la ventana de tiempo de residencia de la generación anterior;
(2) La página insertada en el encabezado de la generación anterior no se colocará en el encabezado de la nueva generación incluso si se accede a ella inmediatamente;
(3) Solo cuando cumpla con el requisito de "visitado" y el "tiempo de permanencia en la generación anterior" sea mayor que T, se le asignará la cabeza a la generación joven;
Para continuar con el ejemplo, si se escanean los datos del lote, se accederá a cinco páginas, como 51, 52, 53, 54, 55 en secuencia.
Si no existe una estrategia de "ventana de tiempo de residencia de la vieja generación", estas páginas a las que se accede en lotes intercambiarán una gran cantidad de datos importantes.
Después de agregar la estrategia de "ventana de tiempo de permanencia de la vieja generación", las páginas que se cargan en una gran cantidad en poco tiempo no se insertarán en el encabezado de nueva generación inmediatamente, sino aquellas páginas a las que se ha accedido solo una vez en un corto período de tiempo. el tiempo se eliminará primero.
Y solo si la generación anterior permanece el tiempo suficiente y el tiempo de permanencia es mayor que T, se insertará en la cabeza de la generación joven.
¿Los principios anteriores corresponden a qué parámetros en InnoDB?
Hay tres parámetros más importantes.
参数： innodb_buffer_pool_size
Introducción : Configure el tamaño de la agrupación de búfer. Cuando la memoria está permitida, DBA a menudo recomienda aumentar este parámetro. Cuantos más datos e índices se pongan en la memoria, mejor será el rendimiento de la base de datos.
Parámetros : innodb_old_blocks_pct
Introducción : La relación entre la generación anterior y la longitud de toda la cadena LRU es 37 por defecto, es decir, la relación entre la longitud de la generación joven y la generación anterior en toda la LRU es 63:37.
Voz en off: si este parámetro se establece en 100, degenerará en un LRU normal.
Parámetros : innodb_old_blocks_time
Introducción : La ventana de tiempo de permanencia de la generación anterior, la unidad es milisegundos y el valor predeterminado es 1000, es decir, se insertará en el encabezado de la nueva generación solo si las dos condiciones de "visitado" y "permanecer en el la generación anterior supera 1 segundo "se cumplen al mismo tiempo.
para resumir
(1) El grupo de búfer es un mecanismo común para reducir el acceso al disco;
(2) El grupo de búferes generalmente almacena en caché los datos en unidades de páginas;
(3) El algoritmo de administración común del grupo de búfer es LRU , Memcache, OS, InnoDB, todos usan este algoritmo;
(4) InnoDB optimiza LRU ordinario:
- El grupo de búfer se divide en la generación anterior y la generación joven . Las páginas que ingresan al grupo de búfer ingresan primero a la generación anterior, y se accede a la página antes de ingresar a la nueva generación para resolver el problema de fallas de lectura previa.
- Se accede a las páginas y el tiempo empleado en la generación anterior supera el umbral configurado antes de ingresar a la nueva generación para resolver el problema del acceso a los datos por lotes y la eliminación de grandes cantidades de datos calientes.
Las ideas son más importantes que las conclusiones.
Qué problema se resuelve es más importante que la solución.