MySQL запрос такой (он работает, но даже при сорока тысячах книг, запрос из трех слов отрабатывается дольше таймаута вебсервера):

Дело в том, что он работает с очень большой таблицей, структура такая: поле art - это ID книги, поле word это ID слова, поле sec это ID секции в книге и поле cnt это сколько раз слово с этим ID встречается в секции. Нужно выбоать все книги, у которых в одной секции замечены все запрошенные слова. $ArgCounter - это количество поисковых слов (в текущей версии не используется), $CyrString - это условие, где ID слов перечисляются через OR. Таким образом, запрос примет, допустим, такой вид:

Проиндексированно только поле word, потому что размер только этого индекса почти пять гигабайт.


Это сообщение отредактировал(а) skyboy - 18.8.2008, 14:06

Навскидку получается нечто вроде

Однако у меня есть огроменные подозрения, что не все ладно в королевстве Датском... 
Что означает AND sec > 0???

Что-то я не заметил увеличения быстродействия (минут пять уже жду).
AND sec > 0 Означает, что наличие поисковых слов в заголовке (то есть до начала первой секции) не интересно. Это не принципиально, можно убрать из запроса.

Планы запрсов смотри... хотя если нет индексов, по-любому filesearch. А если индекс на 5 гиг - какое уж тут быстродействие...

Праздный интерес... Как на int поле получился индекс в 5 гиг? Сколько записей? 

Четыреста пятьдесят два миллиона записей.

Rigel, подумал, поискал, еще раз подумал и ничего. Скажите, у вас ведь запрос 
SELECT count(1)
FROM `dict2` 
WHERE (word='114' OR word='95' OR word='217')
выполняется так же долго?
Сколько записей он возвращает?

//как-то даже неудобно вам вопросы задавать, т.к., скорее всего помочь не смогу

Кстати, вот тут прочитал инетрестную вещь... Индексы на больших таблицах могут только замедлять выборку. Насколько я понял, это связано с тем, что сервер не может загрузить индекс в память и потому значительно увеличивается кол-во операция чтения с диска.

Также, большой разброс данных по диску замедляет. Можно попробовать выполнить:

*сколько это будет работать на вашей базе сложно представить

Не, подумал - ничего тебе не поможет походу... 
Например, для того чтобы попытаться ускорить написанный мной запрос, потребуется индекс по (`art`,`sec`) - а это почти 8 гигов, сервер столько при всем желании не закэширует.

Те коды я написал "на глаз", сейчас проверил запрос:
SELECT count(1) FROM `dict2`  WHERE (word = '333'  OR  word = '3779'  OR  word = '480')
число 1368290 появилось секунды за две.

Добавлено через 7 минут и 12 секунд

Так не бывает, чтобы нельзя было что-то сделать. Хотя бы от счетчика избавиться.

Вот собсно время обработки таблицы по твоему 5-гектарному индексу.
Но как только встречается нечто, не связанное с индексированным полем, начинает лопатиться вся база. Отсюда и время. Может, все-таки попробовать добавить необходимые запросу индексы? 

PS. Надеюсь, это не боевая БД, а модельная копия?

Да, это копия на локальной машине. Настоящая база будет в несколько раз больше.
Я и надеюсь, что удасться избавиться, прежде всего, от счетчика... но пока что-то ничего в голову не лезет, вот я и написал сюда.   
Что до дополнительных индексов - на моей машине с четырьмя гигами их наличие только замедляет работу. 

исходя из струтуры таблицы заметил что ни одно поле не является уникальным идентификаторм строки
(многие субд этого не любят)
грубо говоря  в каждой книге много секций и еще больше слов



он активно использует индекс по word

может поделить большую таблицу на несколько  по смысловым группам.

типы данных для word наверно varchar? , а для art  и  sec тоже varchar?
почему бы не использовать int или еще лучше (smallint, tinyint  ну или что там есть для мускула ... чтобы уписываться в диапазон )
в вашем уникальном случае все это скажется на производительности.

 

Magnifico, да проблемма не в выборке а в постобработке результат. 

Т.е. основное время съедается имнно постобратокой этого миллиона записей.

Добавлено через 2 минуты и 3 секунды
Rigel, а колическтво секций это нечто фиксированное, или у каждой книги оно разное?