Pourquoi MySQL produit-il autant de fichiers MYD temporaires?

Sur un serveur Debian Linux, hébergeant de nombreux sites Web PHP / MySQL (galeries de photos), j'ai parfois «beaucoup» de fichiers comme /tmp/#sql_6405_58.MYD.

Par exemple aujourd'hui:

[2012-12-15 15:18:11] /tmp/#sql_6405_6.MYD : 88MB
[2012-12-15 15:18:11] /tmp/#sql_6405_3.MYD : 22MB
[2012-12-15 15:18:11] /tmp/#sql_6405_4.MYD : 138MB
[2012-12-15 15:18:11] /tmp/#sql_6405_10.MYD : 88MB
...
[2012-12-15 15:18:11] /tmp/#sql_6405_9.MYD : 15MB
[2012-12-15 15:18:11] /tmp/#sql_6405_65.MYD : 49MB
[2012-12-15 15:18:11] /tmp/#sql_6405_44.MYD : 69MB

(59 fichiers en même temps, pour plus de 6 Go ... oui je surveille les gros fichiers en / tmp)

Malheureusement, il se /tmptrouve sur la même partition que /et il casse temporairement le serveur Web, car il /est plein, je suppose. Ensuite, les fichiers disparaissent et le serveur est de retour à la normale.

Tous les noms de fichiers suivent le #sql_6405_*.MYDmodèle. Je voudrais comprendre quelle opération MySQL implique autant de fichiers temporaires. J'ai environ 2000 bases de données sur ce serveur. Est-il possible de savoir quelle base de données est concernée?

Certaines options peuvent entraîner la matérialisation des tables temporaires sous forme de tables MyISAM ou peuvent être configurées pour la retarder. Gardez à l' esprit que pour les tables temporaires sur disque, il n'y a pas de .frmfichiers, mais seulement .MYDet .MYIfichiers (bien sûr. Le fichier .MYI jamais utilisé car il est impossible indice d' une table de température interne).

Voici les options:

• Variables de table temporaire qui doivent avoir la même taille
  • tmp_table_size
  • max_heap_table_size
• sort_buffer_size
• join_buffer_size

Vous devriez également considérer la documentation MySQL sur l'utilisation de la table de température interne

Les situations où des tables temporaires en mémoire sont créées sont

• S'il existe une clause ORDER BY et une clause GROUP BY différente, ou si ORDER BY ou GROUP BY contient des colonnes de tables autres que la première table de la file d'attente de jointure, une table temporaire est créée.
• DISTINCT combiné avec ORDER BY peut nécessiter une table temporaire.
• Si vous utilisez l'option SQL_SMALL_RESULT, MySQL utilise une table temporaire en mémoire, sauf si la requête contient également des éléments (décrits plus loin) qui nécessitent un stockage sur disque.

Lorsqu'une table temporaire en mémoire dépasse le minimum de (tmp_table_size ou max_heap_table_size), mysqld fait ce qui suit:

• Suspend la requête
• Copie le contenu de la table en mémoire dans une table temporaire MyISAM
• Ignore la table en mémoire
• Continue la requête, en envoyant les données temporaires dans la table temporaire MyISAM

Les situations où les tables temporaires en mémoire sont contournées en faveur du disque sont

• Présence d'une colonne BLOB ou TEXT dans le tableau
• Présence d'une colonne dans une clause GROUP BY ou DISTINCT supérieure à 512 octets
• Présence de toute colonne supérieure à 512 octets dans la liste SELECT, si UNION ou UNION ALL est utilisé

Une certaine diligence est requise pour réduire la création de tables temporaires sur le disque

• Définition de join_buffer_size plus grande
• Définition de sort_buffer_size plus grande
• Définition de tmp_table_size et max_heap_table_size plus grands
• Optimisation des requêtes pour minimiser ou même empêcher les tables temporaires
• Création d'index pour créer une vue pré-triée des données à partir de tables individuelles
• Installation de RAM supplémentaire pour accueillir de grandes tables temporaires en mémoire

Si après une telle diligence, des tables temporaires sont toujours en cours de formation sur le disque, voici une décision désespérée: mapper la création de la table temporaire basée sur le disque à la mémoire.

Voici un moyen rapide et sale de configurer un disque RAM de 16 Go à l'aide de tmpdir

STEP01) Créer un dossier de disque RAM

mkdir /var/mysql_tmpfs

STEP02) Ajoutez ceci à my.cnf

[mysqld]
tmpdir=/var/mysql_tmpfs

STEP03) Ajoutez ceci à / etc / fstab

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

ÉTAPE04) Recharger / etc / fstab

mount -a

STEP05) service mysql restart

Après cela, toutes les tables temporaires qui deviennent MyISAM sont écrites sur le disque RAM. Cela devrait accélérer la création de tables temporaires sur disque.

Essaie !!!

Ce sont des requêtes qui se déplacent sur le disque car les résultats sont trop importants pour la mémoire.

Une fois la requête terminée, l'espace s'efface.

Il n'y a aucun moyen de faire correspondre définitivement ces fichiers temporaires aux requêtes, mais vous pouvez obtenir des indices pour faire une bonne supposition à partir de SHOW FULL PROCESSLIST; ou AFFICHER LE STATUT INNODB; ou en consultant votre journal des erreurs si les requêtes échouent.

Chaque fois que nous utilisons des instructions alter sur la table, il crée les fichiers temporels # sql_6405_3.MYD et une fois terminé, jette la sortie et disparaît.

Modifier les tables oblige MySQL à copier des données entières dans des fichiers temporaires # sql.xxx.MYD et à apporter des modifications aux fichiers temporaires créés, puis à supprimer les fichiers de données d'origine nom_table.MYD et à renommer les fichiers temporaires en nom de table.

Aussi, pour certaines requêtes de tri, il crée des fichiers temporaires.

Comme je l'ai tracé. Cette chose arrive.

Je pense que vous pouvez trouver les requêtes en question sur le journal des requêtes lentes, car les requêtes qui créent de grandes tables temporaires s'exécutent généralement pendant une longue période, c'est ainsi que cela m'a aidé aujourd'hui sur un serveur où j'ai trouvé que la /tmppartition était pleine à cause d'un similaire gros fichier temporaire MySQL, c'était un fichier 4G, j'ai trouvé la requête sur le journal des requêtes lentes et j'ai signalé la requête aux développeurs et ils ont trouvé la corruption sur la requête et ils vont la réparer, il semble que les instructions de MySQL soient limitées alors il a fonctionné pendant longtemps et a écrit un fichier temporaire 4G et rempli la /tmppartition.

Et il y a une autre façon de trouver la cause de ce gros fichier temporaire, c'est binaire donc vous ne pouvez pas le lire directement mais j'ai trouvé que vous pouvez grep le texte contenant dessus en utilisant la commande Linux strings comme celle-ci,

strings name-of-mysql-temp-file

Je me suis assuré à partir des mots du texte de la requête MySQL et je l'ai créée.