|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Поднимаю дамп БД на локальной машине (Windows7 х64), создание индексов самой толстой таблицы MyISAM происходит по не хорошему алгоритму, пытаюсь понять причины...
Изначально на винте с папкой tmpdir около 90гб свободного места, данные таблицы на хосте весят 15гб, индекс 5гб (myd и myi файлы соответственно). Сейчас данные залиты, индекс за 10 часов работы составляет 2.5Гб, также присутсвует файл с расширением tmd, весит 6Гб. В папке tmpdir 5 файлов размером 0 байт, на винте на данный момент 45гб свободного места.
Что ему не хватает? Подскажите куда копать плз, не хочется впустую тратить время...
Неактивен
К утру процедура закончилась, но tmd файл до сих пор присутствует. Кто такой? Зачем нужен? Можно ли безболезненно удалить?
Неактивен
Это временный файлик, он должен был удалиться сам после выполнения
восстановления таблицы. Почему не удалился — не понятно. Восстановление
точно закончилось? Если да — можно удалять.
Вообще, восстанавливаться таблички могут или используя sort buffer, или
используя key buffer — в зависимости от того, что больше (и как по его
мнению будет работать быстрее). Можно при REPAIR выставлять sort_buffer_size
побольше, и восстановление будет идти быстрее.
Неактивен
Восстановление таки закончилось, об этом свидетельствует наличие последующих таблиц. Ок, значит удалим.
В доках сказано, что Repair with keycache используется, когда в tmp разделе не хватает места для копии таблицы. У меня же в tmpdir места было придостаточно. На системном диске и системном tmp - да, места было не достаточно. Могло ли это быть причиной?
Оба указанных буфера выставлены на величину 3Гб, не представляю сколько длилась бы процедура при, скажем, 256мб)))
Неактивен
Ну, там много всяких условий. Вот, например, что пишут разработчики:
repair by sort is used only if the theoretical maximum size of every single index fits into myisam_max_sort_file_size and the theoretical average size of every single index fits into myisam_max_extra_sort_file_size. The default for the latter is 256MB.
If your repair takes several hours, you might think of using the utility 'myisamchk' with the -n (or --sort-recover) option.
http://forums.mysql.com/read.php?21,861 … #msg-86332
Неактивен
paulus написал:
theoretical
Очень уверенное заявление 
Неактивен
