Таблицы MyISAM становятся поврежденными - PullRequest
1 голос
/ 13 июня 2009

иногда я получаю сообщение об ошибке типа «таблица помечена как поврежденная и должна быть исправлена». эта БД (таблицы) использует MyISAM. В последнее время это продолжается. какие могут быть причины? совсем недавно я выполняю пакетную вставку

INSERT INTO table (..., ..., ...) VALUES (...), (...), (...) ...

и он просто завис. или заняло очень много времени, чтобы завершить это кажется мне повешенным. на следующий день, когда я проверил, таблица снова была помечена как поврежденная. когда я пытаюсь использовать mysqlcheck -r, он говорит, что все таблицы в порядке, когда он достиг этой «испорченной» таблицы, он снова завис там…

Итак, что я могу сделать, чтобы предотвратить это. и какие могут быть причины. на БД размещена третья сторона, как я могу это отладить?

InnoDB - более надежный двигатель для использования? Я слышал, что MyISAM быстрее, но другие говорят, что InnoDB тоже может быть быстрым, но для его оптимизации требуется еще немного. Могу ли я заключить, что InnoDB является чем-то более надежным, но в целом медленнее, даже с оптимизацией?

Ответы [ 3 ]

3 голосов
/ 13 июня 2009

Если ваши таблицы повреждены, вы можете использовать команду repair table, чтобы исправить их:

 REPAIR TABLE table;

Если вы запустите myisamchk, когда сервер все еще работает (а вставки / выборки попадают в таблицу), это может быть причиной повреждения ваших таблиц. Большинство проблем с коррупцией, с которыми я сталкиваюсь, - это попытки делать что-то вне сервера (копирование файлов и т. Д.), Пока он все еще работает.

InnoDB медленнее для баз данных только для чтения, потому что у него есть функции (совместимые с ACID, блокировка на уровне строк), которые MyISAM пропускает. Однако, если вы выполняете комбинацию операций чтения и записи, в зависимости от комбинации, InnoDB может предложить серьезные улучшения производительности, поскольку ему не нужно блокировать всю таблицу для выполнения записи. Вы также не сталкиваетесь с проблемами коррупции.

1 голос
/ 14 июня 2009

Перейти с InnoDB.

0 голосов
/ 05 сентября 2009

ок, проблема в том, что база данных компании превысила объем памяти, разрешенный хостинговой компанией. так что, очевидно, никто не сказал компании, что они превысили использование ... паршивый хост, я думаю.

Кстати, MySQL никак не мог знать об этом?

...