Всех приветствую!

Итак, начну сначала. Возникла необходимость в обработке большого количества информации... каждый месяц в базу будет добавляться (в одну таблицу или в разные?) примерно 16 000 000 записей. Таблица состоит из 3 полей: дата, MAC-адрес, IP-адрес.


CREATE TABLE `stat` (
`dt` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`mac` varchar(18) NOT NULL default '',
`ip` varchar(255) NOT NULL default '',
KEY `mac` (`mac`),
KEY `login` (`ip`)
) ENGINE=MyISAM;

Ни одно из полей не является уникальным, т. к. уникальных связок "дата - MAC-адрес - IP-адрес" нет. Каждый IP может быть в любое время под любым MAC-адресом. Надеюсь, я понятно объяснил?!

В данный момент в таблице находится 32 000 000 записей.

mysql> select ip from stat group by ip order by ip limit 1, 10;
...
10 rows in set (51.47 sec)

mysql> select count(ip) from stat group by ip order by ip;
...
320 rows in set (22 min 26.78 sec)

Время выборки меня конечно же не устраивает :( А теперь, внимание, впорос!

Как ускорить выполнение запроса? Подскажите, пожалуйста.

Это не биллинг, но делается для провайдера. Так можно вычислить с каких компьютеров (MAC) выходят в сеть под несколькими логинами (IP).

Запрос, который я выполнил, не будет иметь практического применения. Я решил что он будет потяжелее, чем SELECT count(*) FROM stat; и можно будет видеть какая нагрузка будет при таком объёме данных.

Фактически мне нужен список уникальных IP и список MAC, соответствующих каждому из этих IP.
Также, наоборот: список уникальных MAC и список IP, соответствующие каждому из этих MAC.

Данные можно разбить по месяцам, например, но, как я уже сказал выше, их будет не менее 15 000 000 за каждый месяц. Данные буду поступать скопом раз в неделю, например. Получается что сразу будут добавляться примерно по 3 000 000 новых данных.

Время на повтор первого запроса: 31.17 sec. Второй запрос всё ещё выполняется :)

OS: FreeBSD
CPU: Intel(R) Celeron(R) CPU 2.53GHz
RAM: 256 Мб.
HDD: SCSI, 40 Gb.
MySQL 4.1.19.

Вот выборка по памяти:

mysqladmin variables | grep mem
| innodb_additional_mem_pool_size | 1048576 |
| innodb_buffer_pool_awe_mem_mb | 0 |
| locked_in_memory | OFF |

mysqladmin variables | grep buf
| bdb_log_buffer_size | 32768 |
| bulk_insert_buffer_size | 8388608 |
| innodb_buffer_pool_awe_mem_mb | 0 |
| innodb_buffer_pool_size | 8388608 |
| innodb_log_buffer_size | 1048576 |
| join_buffer_size | 131072 |
| key_buffer_size | 8388600 |
| myisam_sort_buffer_size | 8388608 |
| net_buffer_length | 16384 |
| preload_buffer_size | 32768 |
| read_buffer_size | 131072 |
| read_rnd_buffer_size | 262144 |
| sort_buffer_size | 2097144 |


Может быть нужно что-то ещё?

Наверное так и прийдется поступить... буду сначала обрабатывать входную информацию, а в таблицы записывать результат... чтобы не было дубликата. Спасибо за помощь.

Ну и вопрос в тему. Какое количество данных в MySQL уже может считать критическим для быстрой обработки? 16 млн. записей обрабатываются, как мы видим, даются уже с трудом. Ясное дело что всё зависит от железа, от типа информации и т. д., но всё же. Например, моя таблица описана выше. Какое количество запией для ьаблицы уже критично? Мне необходимо чтобы запросы выполнялись не более нескольких минут (уж никак не 20 минут!) :) Есть мысли?