>P.S.
>Vershinin Egor, мне самому приходилось писать подобные скрипты для анализа работы сервера.
>получалось немногим лучше (если не хуже в некоторых задачах).
>Хранить статистику в БД разумно, логи - нет (у Вас получается хранение
>чего-то среднего). Опытным путем пришел к тому, что необходимо иметь набор
>шаблонов grep для фильтрации интересующей меня информации из лога и еще
>набора специализированных скриптов для ее анализа. Это позволяет решать как текущие
>задачи администрирования, так и получать статистику.

Ну зачем же так человека расстраивать...:) Все же вектор напрвлености нужно задать правильный. Да и те скрипты и бинарники, которыми выпользуетесь начинались с такого же. Только разница в том, что они пользуют временные файлы, а не таблицы. Касательно же сабжа, то здесь гораздо важнее правильно организовать структуру БД и таблиц. То бишь, к чему я веду. Лог в случае его хранения в БД ни вкоем случае нельзя ложить в обну таблицу. Минимум две. Потому что при выборках из таблиц нарушается самый главный принцип БД. В одной ячейке находиться куча данных, которые повторяются. Кстати в этом плане показателен exim, который хранит свой лог в трех файлах. К чему бы это? :) (так наводящая шутка в сторону)
Второе. Для риалтайма статистики необходимо вешать pipe на лог или еще какой изврат придумывать. Объясню зачем - что бы уменьшить нагрузку на проц/память в процессе предварительного парсинга лога и раскидывании по таблицам. Многие данные надо просто банально продумать на начале проектирования. То есть сесть с логом типичным. Хотя бы на 50-100 строк. Посмотреть какие данные проходят. что надоть, что нет. Взять лист бумаги и нарисовать таблички. Потом связи между ними.  Взять еще один и снова. Но уже на основе предыдущего. И так до тех пор, пока у вас не окажетьсяв итоге несколько таблиц. в которых будут присутсвовать минимум данных. и минимум будет повторятся. Плюс доводите до того, что бы всякие varchar сводились тоже к минимуму. Например смысл присутствия имя hostname если его можно заменить на 1, введя дополнительно таблицу:
+--+---------+
|id| hostname|
+--+---------+
| 1|server.ua|
+--+---------+
| 2|server.ru|
+--+---------+

Даже в случае если используется только один сервер какой прирост, плюс уменьшение объема места, засчет использования не 4-х байт, а 2-х, например (точно размерность не вспомню для varchar  и того же smallint).
Введение правильных ключей при частых выборках, а не раз впятилетку, позволит добиться того, что если например при выполнении первого запроса выборка шла 5 минут, то второй пробежиться за минуту. На что я выше кстати уже указал.
Еще раз возвращаясь к структуре таблицы primary key(month,day,time) все же выбран неудачно, так как нагрузка у автора явно маленькая и письма ходят редко,  то ему оно подойдет, а вот на больших объемах нет - так как очень часто primary key будет повторятся, соответственно в базу данные попадать не будут (дублирование primary невозможно по определению).
ТО есть, Женя, Мысль у тебя хорошая. И даже нужная. Только еще сырая. Я сам такую гадость сейчас пишу. Только я пишу не единичную, а суммарную для нескольких серваков. Потому так и разжевываю, что и зачем. Касательно предыдущих ораторов, того же Сергея, могу сказать, что скорее всего статистику они генерят один раз и забывают об этом. Если тебе нужен именно такой вариант, то то, что ты написал, действительно не имеет смысла, если нужно, что-то более серьезное - тогда продолжай копать.
Для меня такая проблема встала, когда пришлось частенько парсить логи нескольких почтовиков, при чем у каждого он разросся от полутора до 2-х с половиной гигов. И просто статистика типа сколько от и до пользователя прошло писем мне была не нужна. Мне нужны были данные, как прошло конкретное письмо в конкретном интервале времени,возможность вернуть лог полностью и касательно одного письма, и т.д. А это уже слишком специфичные задачи и большинству они нафиг не нужны.