¿Es malo crear muchas tablas temporales mysql simultáneamente?

Necesito hacer análisis estadísticos pesados ​​para entregar algunos datos a los usuarios. Actualmente, capturo los datos de mysql y los proceso a través de PHPmatrices. Sin embargo, las tablas temporales de mysql son bastante mejores (extremadamente más eficientes y más rápidas que las matrices PHP; obviamente debido a su mecanismo).

Mi solución tentativa es formar una tabla temporal sobre cada solicitud (es decir, conexión) para importar y procesar los datos. Sin embargo, no estoy seguro de si existe un inconveniente para crear muchas tablas temporales simultáneamente.

¿Puede esto causar problemas para el servidor mysql? ¿O puedo usarlo como una alternativa a las matrices PHP en numerosas solicitudes simultáneas?

Desea evitar la creación de tablas temporales tanto como sea posible: evite copiar en la tabla temporal (sql)

No funcionan bien en MySQL Replication: ¿Cómo se actualizan los binlogs para las tablas temporales de MySQL?

Dado que las tablas temporales son una realidad en el mundo de DB, es posible que tenga que hacer algunos cambios poco ortodoxos para acomodar su existencia.

Normalmente, mysqld tiene la costumbre de colocar tablas tmp en /tmpo donde tmpdir esté configurado. Eso suele estar en algún disco pobre y desprevenido.

Una alternativa interesante sería configurar un disco RAM y reconfigurar tmpdir para usarlo

PASO 01: Cree un punto de montaje para un disco RAM

mkdir /var/tmpfs

PASO 02: Agregue el disco RAM a / etc / fstab (16GB)

echo "none   /var/tmpfs              tmpfs   defaults,size=16g        1 2" >> /etc/fstab

PASO 03: Agregue esta línea a /etc/my.cnf

[mysqld]
tmpdir=/var/tmpfs

PASO 04: Habilite el disco RAM

Puede hacer uno de los siguientes:

1. Simplemente reinicie el servidor DB
2. mount -t tmpfs -o size=16g none /var/tmpfs

Antes de hacer esto, asegúrese de tener suficiente RAM

Darle una oportunidad !!!

"Muchas tablas temporales de mysql" - Los posibles problemas:

• table_open_cache (y otros ajustables): podría (pero no es probable) alcanzar algún límite
• Hinchazón de carnero: podría (pero no es probable) usar más carnero. Si esto lleva a un intercambio, eso es realmente malo.

No me preocuparía por "muchos" a menos que realmente tenga cientos de tablas temporales a la vez.

¿Cuántos subprocesos (SHOW PROCESSLIST; ignorar 'Sleep') se ejecutan a la vez? Incluso un sistema ocupado rara vez tiene más de 10 a la vez.

Para tablas temporales implícitas , veamos los SELECT que las están causando; Es posible rediseñar las consultas para evitar las tablas temporales.

No me gusta usar un disco RAM: quita la RAM de otras posibilidades de almacenamiento en caché y corre el riesgo de alcanzar un límite estricto (el tamaño del disco).