Par rapport aux tables de données utilisateur ordinaires, les tables temporaires dans MySQL/InnoDB devraient être très peu familières à tout le monde. De plus, le timing et le lieu de création des différentes tables temporaires ne sont pas fixés, ce qui augmente encore le mystère. Le plus insaisissable est que les tables temporaires créent souvent d'abord des fichiers, puis suppriment les fichiers sans rien faire, laissant ainsi une poignée de lecture et d'écriture. Cela donne aux gens l'impression que le dragon a vu le début mais pas la fin. Cet article analyse en détail les méthodes de traitement des tables temporaires dans différentes versions de MySQL. J'espère qu'il sera utile à tout le monde.
Pour être précis, il existe deux types de tables temporaires dont nous parlons souvent. L'une est en réalité une table, utilisée pour stocker les données envoyées par l'utilisateur. .L'interface de lecture et d'écriture de table est utilisée pour l'écriture.La table doit exister sur le système de fichiers lors de la lecture et de l'écriture.L'autre type doit être un fichier temporaire utilisé pour stocker les données dans le processus intermédiaire de calcul SQL. effectué via l'interface de lecture et d'écriture de fichier, le fichier peut avoir été supprimé pendant la lecture et l'écriture, laissant un descripteur de fichier pour l'opération.
Tutoriels associés : Tutoriel vidéo MySQL
Les tables temporaires peuvent être divisées en tables temporaires de disque et en tables temporaires de mémoire les tables et les fichiers temporaires n'existeront que sur le disque, pas dans la mémoire. Plus précisément, les formes de mémoire des tables temporaires incluent le moteur de mémoire et le moteur Temptable. La principale différence réside dans la méthode de stockage des types de caractères (varchar, blob, type de texte). Le premier utilise un espace de longueur fixe pour stocker quel que soit le nombre réel de caractères. . Ce dernier L'opérateur utilisera un espace de stockage de longueur variable, ce qui améliore l'efficacité du stockage dans la mémoire. Plus de données peuvent être traitées dans la mémoire au lieu d'être converties en table temporaire sur disque. Le moteur Memory est disponible depuis le début de la version 5.6 et Temptable est un nouveau moteur introduit dans la version 8.0. D'un autre côté, il existe trois formes de tables temporaires de disque, l'une est une table MyISAM, l'autre est une table temporaire InnoDB et l'autre est une table de mappage de fichiers Temptable. La dernière méthode est fournie par 8.0.
Dans la version 5.6 et les versions précédentes, la table temporaire du disque est placée dans le répertoire temporaire configuré dans la base de données, et l'annulation de la table temporaire du disque est placée avec l'annulation de la table ordinaire (notez que le disque La table temporaire sera redémarrée après le redémarrage de la base de données. Elle a été supprimée ultérieurement. Il n'est pas nécessaire de redolog pour garantir l'intégrité de la transaction via une récupération sur incident, il n'est donc pas nécessaire d'écrire redolog, mais l'annulation est toujours nécessaire car elle est nécessaire. pour prendre en charge la restauration).
Après MySQL 5.7, les données et les annulations de la table temporaire du disque sont séparées et placées dans un espace table séparé ibtmp1. La raison pour laquelle les tables temporaires sont séparées est principalement pour réduire la surcharge liée à la maintenance des métadonnées lors de la création et de la suppression de tables.
Après MySQL 8.0, les données de la table temporaire du disque sont placées séparément dans le pool d'espaces de table temporaire de session (fichier ibt dans le répertoire #innodb_temp), et l'annulation de la table temporaire est placée dans la table globale. espace ibtmp1. Une autre grande amélioration est que l'espace occupé par les données de la table temporaire du disque dans la version 8.0 peut être libéré vers le système d'exploitation après la déconnexion, alors que dans la version 5.7, il doit être redémarré avant de pouvoir être libéré.
Les tables temporaires sont actuellement utilisées dans les deux situations suivantes :
Cela est fait explicitement par les utilisateurs Pour les tables créées par en exécutant la commande create temporary table, le type de moteur est soit explicitement spécifié, soit la valeur de configuration par défaut (default_tmp_storage_engine) est utilisée. L'utilisation de la mémoire suit la méthode de gestion de la mémoire du moteur spécifié. Par exemple, les tables InnoDB seront mises en cache dans le pool de tampons, puis réécrites dans le fichier disque via le thread sale.
Dans 5.6, la table temporaire du disque se trouve sous tmpdir et le nom du fichier est similaire à #sql4d2b_8_0.ibd, où #sql est un préfixe fixe, 4d2b est la représentation hexadécimale du numéro de processus, et 8 est la représentation hexadécimale du numéro de thread MySQL (id dans show processlist), 0 est une valeur incrémentielle commençant à 0 pour chaque connexion, et ibd est la table temporaire du disque d'innodb (contrôlée par le paramètre default_tmp_storage_engine). Dans la version 5.6, une fois la table temporaire du disque créée, les fichiers frm et moteur correspondants sont créés sous tmpdir et peuvent être visualisés via la commande ls du système de fichiers. Une fois la connexion fermée, les fichiers correspondants sont automatiquement supprimés. Par conséquent, si nous voyons de nombreux noms de fichiers au format similaire dans le répertoire tmpdir de la version 5.6, nous pouvons utiliser les noms de fichiers pour déterminer quel processus et quelle connexion utilisent la table temporaire. Cette technique est particulièrement applicable lors du dépannage du problème posé également par le répertoire tmpdir. beaucoup d'espace. Ce type de table temporaire explicitement créée par l'utilisateur sera automatiquement libérée et l'espace sera restitué au système d'exploitation lorsque la connexion sera libérée. L'annulation de la table temporaire est stockée dans l'espace table d'annulation et placée avec l'annulation de la table ordinaire. Avec les segments d'annulation d'annulation, les tables temporaires créées par les utilisateurs peuvent également prendre en charge la restauration.
Dans la version 5.7, la table du disque temporaire se trouve dans le fichier ibtmp, et l'emplacement du fichier ibtmp et la méthode de contrôle de la taille sont contrôlés par le paramètre innodb_temp_data_file_path. Les données et l'annulation des tables explicitement créées se trouvent dans ibtmp. Une fois la connexion utilisateur déconnectée, la table temporaire sera libérée, mais simplement en la marquant dans le fichier ibtmp, l'espace ne sera pas restitué au système d'exploitation. Si vous souhaitez libérer de l'espace, vous devez redémarrer la base de données. De plus, une chose à noter est que dans la version 5.6, vous pouvez voir directement le fichier créé sous tmpdir, mais dans la version 5.7, il est créé dans l'espace table ibtmp, vous ne pouvez donc pas voir le fichier de table spécifique. Si vous avez besoin de l'afficher, vous devez afficher la table INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO. Elle contient un nom de colonne. Vous pouvez voir le nom de la table ici. La spécification de dénomination est similaire à celle de la version 5.6, de sorte que les connexions qui occupent beaucoup d'espace peuvent également être trouvées rapidement.
Dans la version 8.0, les données et l'annulation de la table temporaire sont encore séparées. Les données sont stockées dans le fichier ibt (contrôlées par le paramètre innodb_temp_tablespaces_dir), et l'annulation est toujours stockée dans le fichier ibtmp (. toujours contrôlé par le paramètre innodb_temp_data_file_path control). Celui qui stocke les fichiers ibt est appelé espace de table temporaire de session, et l'ibtmp qui stocke l'annulation est appelé espace de table temporaire global. Voici une introduction à l'espace table temporaire Session qui stocke les données. L'espace table temporaire de session apparaît sur le disque sous la forme d'un ensemble de pools de fichiers composés de fichiers ibt. Au démarrage, la base de données sera recréée dans le répertoire configuré et supprimée à la fermeture de la base de données. Au démarrage, 10 fichiers ibt seront créés par défaut, et chaque connexion en utilisera jusqu'à deux, un pour la table temporaire créée par l'utilisateur, et l'autre pour la table temporaire implicite créée par l'optimiseur décrit ci-dessous. Bien entendu, la table temporaire ne sera créée que lorsqu'elle sera nécessaire. Si elle n'est pas nécessaire, le fichier ibt ne sera pas occupé. Lorsque les 10 ibts seront utilisés, la base de données continuera à être créée, avec un maximum de 400 000 créés. Lorsque la connexion est libérée, le fichier ibt utilisé par la connexion sera automatiquement libéré et l'espace sera récupéré. Si vous souhaitez récupérer l'espace table temporaire global, vous devez toujours redémarrer. Cependant, puisque les fichiers stockant les données ont été séparés et prennent en charge le recyclage dynamique (c'est-à-dire que de l'espace est libéré lorsque la connexion est déconnectée), le problème d'occupation de l'espace qui préoccupait tout le monde depuis longtemps sur 5.7 a été grandement atténué. Bien sûr, il reste encore de la place pour l'optimisation. Par exemple, l'espace doit être libéré après la déconnexion de la connexion. En théorie, beaucoup d'espace peut être libéré après certains SQL (par exemple, lorsque l'utilisateur supprime une table temporaire créée explicitement). est exécuté. De plus, si vous avez besoin d'afficher le nom de la table, affichez toujours la table INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO. Il convient de noter que sur 8.0, les tables temporaires explicites ne peuvent pas être des tables compressées, mais que les versions 5.6 et 5.7 le peuvent.
Ce type de table temporaire est une table auxiliaire créée par la base de données pour aider à l'exécution de certains SQL complexes. table requise ? , généralement déterminée par l'optimiseur. Contrairement à la création directe de fichiers disque pour les tables temporaires explicitement créées par les utilisateurs, si l'optimiseur estime que SQL a besoin de l'aide d'une table temporaire, il utilisera d'abord la mémoire de la table temporaire si elle dépasse la mémoire configurée (min(tmp_table_size, max_heap_table_siz)). , elle sera convertie en table temporaire de disque, ce type de table temporaire de disque est similaire à celle explicitement créée par l'utilisateur. Le type de moteur est contrôlé par le paramètre internal_tmp_disk_storage_engine. Généralement, les requêtes légèrement plus complexes, y compris, mais sans s'y limiter, order by, group by, distinct, etc., utiliseront cette table temporaire créée implicitement. Les utilisateurs peuvent utiliser la commande expliquer pour voir s'il y a un mot comme « Utilisation temporaire » dans la colonne Extra. Si tel est le cas, une table temporaire doit être utilisée.
En 5.6, la table temporaire implicite est toujours sous tmpdir Lors de l'exécution de SQL complexe, vous pouvez voir cette table temporaire une fois l'exécution terminée, elle sera supprimée. Il est à noter qu'en 5.6, cette table temporaire créée implicitement ne peut être utilisée qu'avec le moteur MyISAM, c'est-à-dire qu'il n'y a pas de paramètre internal_tmp_disk_storage_engine pour la contrôler. Par conséquent, lorsqu'il n'y a que la table innodb dans notre système, nous verrons également certains indicateurs de MyISAM changer. Dans ce cas, cela est généralement dû à la table temporaire implicite.
Dans la version 5.7, la table temporaire implicite est créée dans le fichier ibtmp. Une fois le SQL terminé, elle sera marquée pour suppression, mais l'espace ne sera toujours pas restitué au système d'exploitation si nécessaire. être renvoyé, la base de données doit être redémarrée. De plus, 5.7 prend en charge le paramètre internal_tmp_disk_storage_engine et les utilisateurs peuvent choisir les tables InnoDB ou MYISAM comme tables temporaires de disque.
Dans la version 8.0, des tables temporaires implicites sont créées dans l'espace table temporaire de session, c'est-à-dire placées avec les données des tables temporaires explicitement créées par l'utilisateur. Si une connexion nécessite une table temporaire implicite pour la première fois, la base de données en prendra une dans le pool composé de fichiers ibt que la connexion utilisera jusqu'à ce que la connexion soit libérée. Comme mentionné ci-dessus, nous avons également mentionné que dans la version 8.0, les tables temporaires explicitement créées par les utilisateurs se verront également attribuer un ibt du pool à utiliser. Chaque connexion utilise jusqu'à deux fichiers ibt pour stocker les tables temporaires. Nous pouvons interroger INFORMATION_SCHEMA.INNODB_SESSION_TEMP_TABLESPACES pour déterminer où se trouve le fichier ibt. Dans ce tableau, chaque fichier ibt représente une ligne et il existe plusieurs lignes pour plusieurs fichiers ibt dans le système actuel. Il y a une colonne appelée ID Si cette colonne est 0, cela signifie que cet ibt n'est pas utilisé. Si elle est non-0, cela signifie que la connexion avec cet ID est en cours d'utilisation. cela signifie que la connexion avec process_id 8 utilise ce fichier ibt. De plus, il existe une colonne d'objectif. La valeur INTRINSIC indique que la table temporaire implicite utilise cet ibt, et USER indique que la table temporaire affichée est en cours d'utilisation. De plus, il existe une taille de colonne indiquant la taille actuelle. Les utilisateurs peuvent interroger cette table pour déterminer l'utilisation des tables temporaires dans l'ensemble de la base de données, ce qui est très pratique.
En 5.6 et 5.7, les tables temporaires en mémoire ne peuvent utiliser que le moteur Memory. En 8.0, il existe un choix supplémentaire de moteur Temptable. Temptable utilise un stockage de longueur variable dans son format de stockage, ce qui peut économiser de l'espace de stockage, améliorer encore l'utilisation de la mémoire et réduire le nombre de conversions en tables temporaires sur disque. Si l'ensemble de tables temporaires du disque est InnoDB ou MYISAM, une copie de conversion est requise. Afin de réduire au maximum la consommation, Temptable propose un mécanisme de débordement, c'est-à-dire que si la table temporaire de mémoire dépasse la taille configurée, la méthode de mappage d'espace disque est utilisée, c'est-à-dire qu'un fichier est ouvert puis supprimé, laissant un handle pour les opérations de lecture et d’écriture. Le format de lecture et d'écriture des fichiers est le même que le format en mémoire, donc l'étape de conversion est ignorée et les performances sont encore améliorées. Notez que cette fonctionnalité n'est disponible que dans la version 8.0.16, qui n'a pas encore été publiée. Le code n'étant pas encore visible, nous ne pouvons deviner son implémentation qu'à travers la documentation. Dans la version 8.0.16, le paramètre internal_tmp_disk_storage_engine a été supprimé et la table temporaire du disque ne peut utiliser que le formulaire InnoDB ou le formulaire de débordement de TempTable. D'après la documentation, il semble que la recommandation officielle soit d'utiliser le nouveau moteur TempTable. Des améliorations de performances spécifiques devront être testées après la publication du code avant que nous puissions tirer des conclusions.
Par rapport aux tables temporaires, les fichiers temporaires peuvent être moins familiers à tout le monde. Les fichiers temporaires sont davantage utilisés dans les scénarios de mise en cache et de tri des données. Dans des circonstances normales, les données mises en cache ou triées sont d'abord placées en mémoire. Si la mémoire ne peut pas être stockée, les fichiers temporaires sur le disque seront utilisés. L'utilisation des fichiers temporaires est différente de celle des tables générales. Une fois la table générale créée, elle commence à lire et à écrire des données, et le fichier est supprimé après utilisation. Cependant, l'utilisation des fichiers temporaires est différente une fois la table créée. (Utilisez la fonction système mkstemp), appelez immédiatement unlink pour supprimer le fichier, mais ne fermez pas le fichier, puis utilisez le handle d'origine pour faire fonctionner le fichier. L'avantage est que lorsque le processus plante anormalement, aucun fichier temporaire ne reste car ils n'ont pas été supprimés, mais les inconvénients sont également évidents lorsque nous utilisons la commande ls sur le système de fichiers. utilisez lsof +L1 pour afficher les fichiers avec cet attribut supprimé.
Actuellement, nous utilisons principalement des fichiers temporaires dans les scénarios suivants :
Dans le processus de création de DDL en ligne, il existe De nombreuses opérations La table d'origine doit être reconstruite.Avant de reconstruire la table, divers index secondaires doivent être triés. Il est peu probable que le tri d'une grande quantité de données soit effectué en mémoire et nécessite un algorithme de tri externe. Au cours de ce processus, des fichiers temporaires doivent être créés. Généralement, l'espace requis est à peu près le même que celui de la table d'origine. Cependant, il sera nettoyé immédiatement après utilisation, donc lorsque vous effectuez du DDL, vous devez réserver suffisamment d'espace. Les utilisateurs peuvent spécifier le chemin d'accès à ce fichier de tri en spécifiant innodb_tmpdir. Ce paramètre peut être modifié dynamiquement et est généralement défini sur un chemin avec suffisamment d'espace disque. Le nom du fichier temporaire est généralement similaire à ibXXXXXX, où ib est un préfixe fixe et XXXXXX est une combinaison aléatoire de lettres et de chiffres majuscules et minuscules.
Lors de l'utilisation de DDL en ligne, nous permettons aux utilisateurs d'effectuer des opérations DML sur la table d'origine, c'est-à-dire ajouter, supprimer, modifier et interroger. Nous ne pouvons pas insérer directement dans la table d'origine, nous avons donc besoin d'un endroit pour enregistrer les opérations de modification sur la table d'origine, puis les appliquer à la nouvelle table une fois le DDL terminé. L'endroit où cela est enregistré est le journal en ligne. Bien entendu, s'il y a peu de changements, il peut être stocké directement dans la mémoire (le paramètre innodb_sort_buffer_size peut être contrôlé, et ce paramètre contrôle également la taille de chaque lecture et écriture. bloc du journal en ligne). Ce journal en ligne est également stocké dans un fichier temporaire, créé dans innodb_tmpdir. La taille maximale est contrôlée par le paramètre innodb_online_alter_log_max_size Si elle dépasse cette taille, DDL échouera. Le nom du fichier temporaire est également similaire au nom du fichier temporaire de tri mentionné ci-dessus.
Dans la dernière étape du DDL en ligne, tous les fichiers triés et DML générés au cours du processus doivent être appliqués à un fichier intermédiaire. Le nom du fichier intermédiaire est similaire à #sql-ib53-522550444.ibd, où #sql-ib est un préfixe fixe. , 53 est l'identifiant de table de la couche InnoDB et 522550444 est un nombre généré aléatoirement. Dans le même temps, un fichier frm sera également généré dans la couche serveur (non disponible dans la version 8.0). Le nom du fichier est similaire à #sql-4d2b_2a.frm, où #sql est un préfixe fixe, 4d2b est la représentation hexadécimale de. le numéro de processus, et 2a est le fil de discussion. La représentation hexadécimale du numéro (id dans show processlist). Par conséquent, nous pouvons également utiliser cette règle de dénomination pour trouver quel thread effectue le DDL. Une chose à noter ici est que le fichier intermédiaire mentionné ici est en fait une table temporaire, et non le fichier temporaire mentionné ci-dessus. Ces fichiers intermédiaires peuvent être visualisés via ls. Lors de la dernière étape du DDL, les deux fichiers temporaires seront renommés avec leurs noms de table d'origine. Grâce à cette fonctionnalité, lorsque la base de données tombe en panne à mi-chemin, des fichiers résiduels inutiles peuvent rester sur le disque. Dans ce cas, vous pouvez d'abord renommer le fichier frm avec le même nom que le fichier ibd, puis utiliser DROP TABLE#mysql50##sql-ib53-522550444` pour nettoyer les fichiers restants. Notez que si vous supprimez directement le fichier ibd sans utiliser la commande drop, il peut encore rester des informations résiduelles dans le dictionnaire de données, ce qui n'est pas très élégant. Bien entendu, dans la version 8.0, en raison de l'utilisation du dictionnaire de données atomiques, de tels fichiers résiduels n'apparaîtront pas.
BinLog ne sera écrit dans le fichier que lorsque la transaction est soumise. Avant la soumission, elle sera placée dans la mémoire (contrôlée par le paramètre. binlog_cache_size), si la mémoire ralentit, un fichier temporaire sera créé. La méthode d'utilisation consiste à le créer d'abord via mkstemp, puis à le dissocier directement, en laissant un handle pour la lecture et l'écriture. Le nom du fichier temporaire est similaire à MLXXXXXX, où ML est un préfixe fixe et XXXXXX est une combinaison aléatoire de lettres et de chiffres majuscules et minuscules. Si le BinLog d'une seule transaction est trop grand, la taille de l'ensemble du BinLog peut être trop grande, affectant ainsi la synchronisation. Par conséquent, nous devons contrôler la taille de la transaction autant que possible.
Certaines opérations, en plus de s'appuyer sur des tables temporaires implicites au niveau de la couche moteur pour aider au calcul de SQL complexes, seront également créés au niveau du serveur Les fichiers temporaires sont utilisés pour aider, comme l'ordre par opération, qui appellera la fonction de tri de fichiers. Cette fonction utilisera également d'abord la mémoire (sort_buffer_size) pour trier. Si cela ne suffit pas, elle créera un fichier temporaire pour faciliter le tri. Le nom du fichier est similaire à MYXXXXXX, où MY est un préfixe fixe et XXXXXX est une combinaison aléatoire de lettres et de chiffres majuscules et minuscules.
Dans la réplication BinLog, si la commande Load Data est utilisée sur la base de données principale, c'est-à-dire que les données sont importées du fichier , la base de données écrira l'intégralité du fichier dans le RelayLog, puis le transférera vers la base de données de secours. La base de données de secours analyse le RelayLog, extrait le fichier de chargement correspondant, puis l'applique à la base de données de secours. L'emplacement où ce fichier est stocké sur la base de données de secours est contrôlé par le paramètre slave_load_tmpdir. Le document recommande de ne pas configurer ce répertoire dans le répertoire mémoire de la machine physique ou dans un répertoire qui sera supprimé après redémarrage. La réplication s'appuyant sur ce fichier, si celui-ci est accidentellement supprimé, la réplication sera interrompue.
En plus des endroits mentionnés ci-dessus, il existe plusieurs autres endroits où les fichiers temporaires sont également utilisés :
*** tmpdir : *** Ce paramètre est la configuration du répertoire temporaire Dans la version 5.6 et les versions précédentes, les tables/fichiers temporaires seront placés ici par. défaut. Ce paramètre peut être configuré avec plusieurs répertoires, de sorte que des tables/fichiers temporaires puissent être créés tour à tour dans différents répertoires. Si différents répertoires pointent vers des disques différents, l'objectif de déchargement peut être atteint.
*** innodb_tmpdir : *** Ce paramètre n'est utilisé que par le tri des fichiers temporaires en DDL. Cela prend beaucoup de place, il est donc recommandé de le configurer séparément. Ce paramètre peut être défini dynamiquement et est également une variable de session.
*** slave_load_tmpdir : *** Ce paramètre est principalement utilisé lors de la configuration de l'emplacement du fichier temporaire de la bibliothèque de sauvegarde lors du chargement des données dans la réplication BinLog. Étant donné que la base de données doit toujours s'appuyer sur le chargement des fichiers de données après un crash, il est recommandé de ne pas configurer un répertoire qui supprimera les données après le redémarrage.
*** internal_tmp_disk_storage_engine : *** Lorsqu'une table temporaire implicite est convertie en table temporaire de disque, quel moteur est utilisé, la valeur par défaut est uniquement MyISAM et InnoDB. Uniquement pris en charge par les versions 5.7 et ultérieures. Ce paramètre a été annulé après la version 8.0.16.
*** internal_tmp_mem_storage_engine : *** Le moteur de stockage utilisé lorsque la table temporaire implicite est en mémoire, vous pouvez choisir Mémoire ou Moteur temptable. Il est recommandé de choisir le nouveau moteur Temptable.
*** default_tmp_storage_engine : *** Le moteur de tables temporaires explicites par défaut, c'est-à-dire le moteur de tables temporaires créées par les utilisateurs via des instructions SQL.
*** tmp_table_size : *** min(tmp_table_size,max_heap_table_size) est la taille de la mémoire de la table temporaire implicite si elle dépasse cette valeur, elle sera convertie en table temporaire de disque.
*** max_heap_table_size : *** La taille limite de mémoire de la table mémoire créée par l'utilisateur.
*** big_tables : *** La conversion d'une table temporaire de mémoire en table temporaire de disque nécessite une opération de conversion, qui doit être convertie dans différents formats de moteur. Elle est consommée. Si nous pouvons savoir à l'avance qu'une table temporaire de disque est nécessaire pour exécuter un certain SQL, c'est-à-dire que la mémoire n'est certainement pas suffisante, nous pouvons définir ce paramètre pour que l'optimiseur ignore l'utilisation de la table temporaire de mémoire et utilise directement le disque. table temporaire pour réduire les frais généraux.
*** temptable_max_ram : *** Ce paramètre n'est disponible qu'après la version 8.0. Il est principalement utilisé pour spécifier la taille de la mémoire du moteur Temptable. Après avoir dépassé cette valeur, il sera soit converti en table temporaire de disque, soit utilisé. mécanisme de trop-plein intégré.
*** temptable_use_mmap : *** S'il faut utiliser le mécanisme de débordement de Temptable.
Les tables et fichiers temporaires de MySQL sont en fait un sujet relativement complexe, impliquant de nombreux modules, et le moment d'apparition est plus difficile à comprendre, ce qui entraîne des problèmes de dépannage par rapport aux problèmes ordinaires. les tableaux. C'est assez difficile. Il est recommandé aux lecteurs d'étudier attentivement le code afin de localiser les problèmes difficiles pouvant survenir en ligne.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
mysql modifier le nom de la table de données
MySQL crée une procédure stockée
La différence entre MongoDB et MySQL
Comment vérifier si le mot de passe MySQL est oublié
mysql créer une base de données
niveau d'isolement des transactions par défaut de MySQL
La différence entre sqlserver et mysql
mysqlmot de passe oublié
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
