Есть ли способ дефрагментировать MySQL-таблицу типа MEMORY?

Задача — нужно вести Web-логи. Не много, фактически — учёт посещений всеми пользователями всех ресурсов за 10-20 минут. На моих проектах это порядка (максимум) тысяч-десятков тысяч записей, каждая суммарной длиной в десяток-другой килобайт. Хранить нужно много разной информации и делать сложные выборки. Так что лучше MySQL ничего не придумал.

Проблема. На высокой активности MySQL какого-то фига начинает сильно грузить IO. Ладно, хранить данные всё равно не надо, делаю ENGINE=MEMORY. Отлично, IO резко падает, всё красиво.

Проблема №2. Поскольку таблица постоянно чистится, накапливается высокий уровень фрагментации. И вот тут — опа. Таблицы Memory не оптимайзятся. Уровень мусора постоянно растёт, пока размер таблицы не превысит tmp_table_size/max_heap_table_size, после чего начинают лететь ошибки «table is full». Фигня выходит, реальных данных в таблице едва несколько десятков мегабайт, а жрёт она пол-гига в памяти.

Как её оптимизировать? Есть идеи?

Есть, конечно, вариант, типа раз в час тупо грохать все данные, они не настолько критичны. Но криво.

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

Какие ещё есть варианты?

Или, может, что-то вместо MySQL применить? Нужно хранить по каждому обращению несколько данных (строковых, целочисленных, с плавающей точкой), делать очень частое получение суммы по одному из параметров (суммарная загрузка — для выдачи 503 ошибки чрезмерно активным ботам и качальщикам) и периодические группировки по ряду параметров (изучение активности по классам/категориям объектов сайта и посетителей).