Автор оригинала: Сергей Тарасов
Итак у тебя 200 млн записей
Тогда представь сколько памяти и времени у тебя сожрет 4000 таких запросов???
select id, ts from table limit 0,50000
С master_x полностью согласен.
Все, что я говорю - только про InnoDB.
в том то и дело, что при таком (select id, ts from table limit 0,50000) запросе не юзаются вообще никакие индексы, не определяется порядок записей и пр. Такой селект выполняется в пределе со скоростью работы винтов и сети. Это очевидно, надеюсь, безо всяких тестов. Исключение - когда от _очень_ большой нагрузки слишком неправдоподобно большая cardinality у первичного ключа.
Если рассмотреть запрос с группировкой:
Пусть даже у нас есть хороший ключ по ts. Для группировки (даже с лимитом) мускул должен пройти по всему куску дерева ключа, который подходит под where ( у нас where нет).
Да, я правда написан слишком простой случай, признаю. Здесь проход по дереву, возможно, получится, здесь нет необходимости обращаться к данным вообще...
Стоило рассмотреть все-таки структуру типа
Код:
CREATE TABLE `table_name` (
`id` bigint(20) NOT NULL auto_increment,
`request_id` int(10) unsigned NOT NULL default '0',
`region_id` int(10) unsigned NOT NULL default '0',
`position` int(10) unsigned NOT NULL default '0',
`created` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`misc` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251
И запрос типа select sum(misc), date(created) as ts from table_name group by ts
Вот здесь даже если сделать индекс по created, мускулу придется пройти в случайном порядке по всем записям в таблице. Это, естественно, слишком долго.
-~{}~ 03.03.06 17:36:
Фанат
К счастью, я уже давно не делаю таких сложных запросов по большим таблицам. Когда-то сравнивал оба способа именно на таких объемах. Это было слишком давно, и логи, естественно, не сохранились. Думаю, я привел достаточно полное описание проблем, чтобы доказательство считать очевидным. Могу только сказать, что сейчас метод простых селектов успешно работает на наших серверах и справляется с нагрузкой в 200-300 млн. обработанных записей/сутки на один сервер с loadavg 1-2.
