MySQL, ошибка 126: неверный ключевой файл для таблицы
Я прочитал следующий вопрос, который имеет отношение, но ответы не удовлетворили меня: MySQL: # 126 - Неверный ключевой файл для таблицы
Эта проблема
При выполнении запроса я получаю эту ошибку
ОШИБКА 126 (HY000): неверный ключевой файл для таблицы`
Вопрос
Когда я пытаюсь найти проблему, я не могу найти ее, поэтому я не знаю, как ее исправить с помощью команды repair. Есть ли какие-либо указания на то, как я могу найти проблему, вызывающую эту проблему, любым другим способом, чем я уже пробовал?
Запрос
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
mysqlcheck
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
5 ответов
Похоже, что ваш запрос возвращает большой промежуточный набор результатов, требующий создания временной таблицы, и что настроенное расположение для таблиц временных дисков mysql (/tmp) недостаточно велико для получаемой временной таблицы.
Вы можете попробовать увеличить размер раздела tmpfs, перемонтировав его:
mount -t tmpfs -o remount,size=1G tmpfs /tmp
Вы можете сделать это изменение постоянным, отредактировав /etc/fstab
Если вы не можете это сделать, попробуйте изменить расположение временных таблиц на диске, отредактировав запись "tmpdir" в файле my.cnf (или добавьте ее, если ее там еще нет). Помните, что выбранный вами каталог должен быть доступен для записи пользователю mysql
Вы также можете попытаться предотвратить создание временной таблицы на диске, увеличив значения параметров конфигурации mysql:
tmp_table_size
max_heap_table_size
к большим значениям. Вам нужно будет увеличить оба вышеперечисленных параметра
Пример:
set global tmp_table_size = 1G;
set global max_heap_table_size = 1G;
Если твой /tmp mount в файловой системе linux монтируется как переполнение, часто размером 1 МБ, т.е.
$ 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 <------
это скорее всего из-за того, что вы не указали /tmp как его собственный раздел и ваша корневая файловая система заполнена и /tmp был перемонтирован как запасной вариант.
Я столкнулся с этой проблемой после нехватки места на томе EC2. Как только я изменил размер тома, я столкнулся с /tmp Заполнение раздела переполнения при выполнении сложного представления.
Чтобы исправить это после того, как вы очистили пространство / изменили размер, просто размонтируйте запасной вариант, и он должен перемонтироваться в исходной точке (обычно в корневой раздел):
sudo umount -l /tmp
Замечания: -l будет лениво размонтировать диск.
В моем случае я просто очистил временные файлы от временного местоположения:
my.ini
tmpdir = "D: / xampp / tmp"
И это сработало для меня.
Разделение сложного запроса на несколько было бы быстрее без необходимости увеличения размера временной таблицы
Вам просто нужно починить таблицу, которую используете в поисковом запросе. эта проблема обычно возникает в поисковом запросе.
перейти к "table_name" -> operation-> repair (всего одним щелчком мыши). Эффект может занять некоторое время.