J'ai lu la question suivante qui a de la pertinence, mais les réponses ne m'ont pas satisfait: MySQL: # 126 - Fichier de clé incorrect pour la table
Lors de l'exécution d'une requête, j'obtiens cette erreur
ERREUR 126 (HY000): fichier de clé incorrect pour la table`
Lorsque j'essaie de trouver le problème, je ne peux pas en trouver un, donc je ne sais pas comment le résoudre avec la commande de réparation. Y a-t-il des indications sur la façon dont je peux trouver le problème à l'origine de ce problème d'une autre manière que j'ai déjà essayé?
mysql> SELECT
-> Process.processId,
-> Domain.id AS domainId,
-> Domain.Host,
-> Process.started,
-> COUNT(DISTINCT Joppli.id) AS countedObjects,
-> COUNT(DISTINCT Page.id) AS countedPages,
-> COUNT(DISTINCT Rule.id) AS countedRules
-> FROM Domain
-> JOIN CustomScrapingRule
-> AS Rule
-> ON Rule.Domain_id = Domain.id
-> LEFT JOIN StructuredData_Joppli
-> AS Joppli
-> ON Joppli.CustomScrapingRule_id = Rule.id
-> LEFT JOIN Domain_Page
-> AS Page
-> ON Page.Domain_id = Domain.id
-> LEFT JOIN Domain_Process
-> AS Process
-> ON Process.Domain_id = Domain.id
-> WHERE Rule.CustomScrapingRule_id IS NULL
-> GROUP BY Domain.id
-> ORDER BY Domain.Host;
ERROR 126 (HY000): Incorrect key file for table '/tmp/#sql_2b5_4.MYI'; try to repair it
root@scraper:~# mysqlcheck -p scraper
Enter password:
scraper.CustomScrapingRule OK
scraper.Domain OK
scraper.Domain_Page OK
scraper.Domain_Page_Rank OK
scraper.Domain_Process OK
scraper.Log OK
scraper.StructuredData_Joppli OK
scraper.StructuredData_Joppli_Product OK
mysql> select count(*) from CustomScrapingRule;
+----------+
| count(*) |
+----------+
| 26 |
+----------+
1 row in set (0.04 sec)
mysql> select count(*) from Domain;
+----------+
| count(*) |
+----------+
| 2 |
+----------+
1 row in set (0.01 sec)
mysql> select count(*) from Domain_Page;
+----------+
| count(*) |
+----------+
| 134288 |
+----------+
1 row in set (0.17 sec)
mysql> select count(*) from Domain_Page_Rank;
+----------+
| count(*) |
+----------+
| 4671111 |
+----------+
1 row in set (11.69 sec)
mysql> select count(*) from Domain_Process;
+----------+
| count(*) |
+----------+
| 2 |
+----------+
1 row in set (0.02 sec)
mysql> select count(*) from Log;
+----------+
| count(*) |
+----------+
| 41 |
+----------+
1 row in set (0.00 sec)
mysql> select count(*) from StructuredData_Joppli;
+----------+
| count(*) |
+----------+
| 11433 |
+----------+
1 row in set (0.16 sec)
mysql> select count(*) from StructuredData_Joppli_Product;
+----------+
| count(*) |
+----------+
| 130784 |
+----------+
1 row in set (0.20 sec)
root@scraper:/tmp# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 20G 4.7G 15G 26% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 237M 4.0K 237M 1% /dev
tmpfs 49M 188K 49M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 245M 0 245M 0% /run/shm
none 100M 0 100M 0% /run/user
Il semble que votre requête renvoie un grand jeu de résultats intermédiaire nécessitant la création d'une table temporaire et que l'emplacement configuré pour les tables de disques temporaires mysql (/ tmp) n'est pas assez grand pour la table temporaire résultante.
Vous pouvez essayer d'augmenter la taille de la partition tmpfs en la remontant:
mount -t tmpfs -o remount,size=1G tmpfs /tmp
Vous pouvez rendre ce changement permanent en éditant/etc/fstab
Si vous ne parvenez pas à le faire, vous pouvez essayer de modifier l'emplacement des tables temporaires de disque en modifiant l'entrée "tmpdir" dans votre fichier my.cnf (ou l'ajouter si elle n'y est pas déjà). N'oubliez pas que le répertoire que vous choisissez doit être accessible en écriture par l'utilisateur mysql
Vous pouvez également essayer d'empêcher la création d'une table temporaire sur disque en augmentant les valeurs des options de configuration mysql:
tmp_table_size
max_heap_table_size
à des valeurs plus grandes. Vous devrez augmenter les deux paramètres ci-dessus
Exemple:
set global tmp_table_size = 1G;
set global max_heap_table_size = 1G;
Dans mon cas, je supprime simplement les fichiers temporaires de l'emplacement temporaire:
my.ini
tmpdir = "D:/xampp/tmp"
Et ça a marché pour moi.
La division d'une requête complexe en plusieurs requêtes serait plus rapide sans avoir besoin d'augmenter la taille de la table temporaire
Si votre /tmp
le montage sur un système de fichiers linux est monté en débordement, souvent dimensionné à 1 Mo, c'est-à-dire
$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.9G 12K 7.9G 1% /dev
tmpfs 1.6G 348K 1.6G 1% /run
/dev/xvda1 493G 6.9G 466G 2% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 0 5.0M 0% /run/lock
none 7.9G 0 7.9G 0% /run/shm
none 100M 0 100M 0% /run/user
overflow 1.0M 4.0K 1020K 1% /tmp <------
cela est probablement dû au fait que vous ne spécifiez pas /tmp
comme sa propre partition et votre système de fichiers racine rempli et /tmp
a été remonté comme solution de rechange.
J'ai rencontré ce problème après avoir manqué d'espace sur un volume EC2. Une fois que j'ai redimensionné le volume, je suis tombé sur le /tmp
partition de débordement se remplissant lors de l'exécution d'une vue compliquée.
Sudo umount -l /tmp
Remarque: -l
démontera paresseusement le disque.