Teniendo una tabla tan grande deberías usar el motor InnoDB.
Nadie tenia en cuenta que pesara tanto, si no se habría hecho un particionado de tabla por meses, que suele ser lo mas lógico para estos casos si se necesita myisam. De todas formas, por experiencia propia, cuando sabes que va a crecer tanto una tabla directamente la hacemos en mongodb.
En el foro usamos MyISAM porque el ratio de lecturas sigue siendo muy elevado, un 90€ de las consultas son selects. Y la tabla no es tan grande, la de mensajes ocupa 1,2GB myd
A nosotros nos pasa mas o menos lo mismo. Los selects se hacen bastante y se vuelven muy pesados.
Reinicia el servidor mysql y se debería reparar la tabla dañada automáticamente.
Ese recovery no funciona, he hecho recovery con mysqlcheck, que es el automático, creo, con todos sus variantes de parámetros y el myisamchk también. El único que nos queda, que aún está en ello, es el que lleva la opción -o que es el old, el recovery mas viejo, que mas tarda pero que también arregla lo que los otros no arreglan. Hace un rato he podido hacer un cálculo y me ha salido que tardará 7 dias en recuperar solo el fichero MYD, el de indices ni idea.
myisamchk --silent --force --fast --update-state \
--key_buffer_size=512M --sort_buffer_size=512M \
--read_buffer_size=4M --write_buffer_size=4M \
/var/lib/mysql/bugs/*.MYI
Ese también lo hemos hecho pero no funciona. La opción fast peta.
Gracias por el interés.