Привет всем!

Ситуация:
У меня работает MySQL.
Структура таблицы:
---------------------------------------------------------------------
DROP TABLE IF EXISTS `pd_pt_documents`.`_index_a`;
CREATE TABLE `pd_pt_documents`.`_index_a` (
`doc_id` int(10) unsigned NOT NULL,
`hash` int(10) NOT NULL DEFAULT '0',
`fp_offset` int(10) unsigned NOT NULL,
KEY `hash_idx` (`hash`) USING BTREE
) ENGINE=MyISAM DEFAULT CHARSET=utf8 PACK_KEYS=0 ROW_FORMAT=FIXED;
---------------------------------------------------------------------
итого - 3 поля.
Кол-во записей - 200.000.000

Всё что мне нужно это высокоскоростной поиск:

SELECT doc_id, fp_offset, hash FROM _index_a WHERE hash = 0000123
OR hash = 0000123
OR hash = 0000124
OR hash = 0000125
[...]
OR hash = 000999

Особенность:
В секунду на БД посылаеться 10 таких запросов.

Т.е. база просто засыпается сотнями тысяч запросов.

Вопрос: какая СУБД лучше всего справиться с такой задачей?
--
Заранее всем спасибо!

2 miksoft:

У меня немного опыта с SQL -
уточните пожалуйста как именно и зачем "UNION ALL, либо через IN."?

Это повысит быстродействие?

2 Саабразим Аль-каши Бухани:

Скажу спасибо за пинок в нужном направлениии!
Что именно оптимизировать?

2 Yo.! :

Спасибо за идею с IOT! Я немного рогуглил - IOT. Это только Oracle?

2 miksoft :

Замечания - хеши идут НЕ подряд (я подправил примеры)

Структура запроса (старого) была такая:
-----------------------------------------
SELECT doc_id, fp_offset, hash FROM _index_a WHERE hash = 204777
OR hash = -66780123
OR hash = 067831124
OR hash = -345125
[...много других хешей - размер кол-ва хешей регулирую переменной...]
OR hash = 000999
-----------------------------------------

Я почитал про IN и согласно Вашему совету переделал так:
-----------------------------------------
SELECT doc_id, fp_offset, hash FROM _index_a WHERE hash IN (234777,
-36780123,
067831124,
-345125,
[...много других хешей - размер кол-ва хешей регулирую переменной...]
000999)
-----------------------------------------

Быстродействие заметно увеличилось!

Статистика:

В БД - 52.000.000 записей.
Поиск (т.е. вышеописаный SELECT с IN вместо OR) 10000 хешей (размазаны по всем 52 миллионам - т.е.
почти всегда) худший вариант составляет 15-30 секунд.

Насколько я понимаю логику работы БД, наиболее оптимальным вариантом будет
именно максимально большего кол-ва хешей при SELECT-е
чтобы "проход по диску" был только один.

Я обязательно протестирую всё вышеописанное на Orace Index-Organized Tables.

Я стремлюсь к идеалу :-) но

Как ещё можно ускорить процесс?