Приветствую.

Есть таблица с 4-5 полями содержащими в общей сложности около 8 - 11 млн записей. База MySQL

Необходимо очень часто (чаще чем раз в сек) дергать эту таблицу на проверку наличие в ней той или иной записи т.е по сути обычный SELECT

Запись новых данных в таблицу производится не будет.

Вопрос:

Как лучше оптимизировать ?

1) Загрузить всю таблицу сразу и использовать Locate
2) В памяти создать Query и каждый раз делать SELECT
3) Возможно ли воспользоватся поиском записи в таблице средствами mysql сервера (плохо знаю базу, по этому и спрашиваю) - отличным от SELECT. Например использовать хранимую процедуру ?

Поможет ли перевод указаной таблицы с формата InnoDB в формат MyISAM ( учитывая что все остальные таблицы в базе хранятся в формате InnoDB)

Возможно подскажете как еще можно оптимизировать ?

> как еще можно оптимизировать ?
главная скорость в логике! пересмотреть ее и глядишь нужно будет не "(чаще чем раз в сек)", а "раз в час"... оптимизация в 7200 раз!!!
или "чаще чем раз в сек" для одной записи превратится в "раз в минуту для 120"... а по времени разницы между мелкими запросами на 1 или 120 записей практически нет, вот и считай.

Логику не пересмотришь.

Есть задача при добавлении товара в базу проверять данные в таблице. Товары добавляются - редактируются одновременно 200 менеджерами т.е запросы к таблице не уменьшить.

вопрос - каким образом уменьшить нагрузку на приложение и базу исходя из данной задачи ? что лучше хранимая процедура или SELECT ? какой формат таблицы использовать ? Почему ?

> Логику не пересмотришь.
да ну?
чем больше таких безапелляционных заявлений, тем больше у меня сомнений.

> при добавлении товара в базу проверять данные в таблице.
надеюсь понимаешь, что вот этим добавлением перевернул сказанное в [0] на 180 градусов.
чтение, и запись разные вещи, даже если во время записи нужно чтение...
и как же из [0] -
> Запись новых данных в таблицу производится не будет.
???

> Товары добавляются - редактируются одновременно 200 менеджерами т.е запросы к таблице не уменьшить.
не хило у тебя "рабы" по клавишам долбят... раз обеспечивают несколько раз в секунду...

p.s. явно чтото не то, и явно можно изменить логику.
p.p.s.  найди основы по реализации документооборота. можешь взять 1С за пример.

Если не брать в расчет организацию работы, то используй WHERE именно это главный оптимизатор

>dreamse ©   (01.03.12 07:59)
объясните для чего при "добавлении товара" надо "проверять данные в таблице"
авось и нужда-то дергать таблицу-миллионник с такой частотой отпадет

Есть подозрение, что эти 8 миллионов - справочник товаров.
Если да, то все еще трагичнее :)

> Anatoly Podgoretsky ©   (01.03.12 10:32) [4]

Да, это уже использую, дергается не все поля а только одно по которому идет поиск.

Интересует что больше ускорит работу LIKE или хранимая процедура на сервере ?

Вот пример - база данных антиаирусных мониторов - записей миллионы

но при этом сканнер в секунды проверяет тысячи файлов на наличие записи в БД - код сигнатуры, MD5 и пр которые хранятся в таблицах.

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

Рассуждать о логике прошу прекратить, вопрос был не в этом.
Соглашатся с вами о том что нужно менять логику не буду, есть задача, есть вопрос никаким образом не относящийся к логике ...

>dreamse ©   (01.03.12 13:09) [8]

коли:
>Рассуждать о логике прошу прекратить, вопрос был не в этом.

и с учетом:
>Интересует что больше ускорит работу LIKE или хранимая процедура на сервере ?

то на выбор:
1. учить SQL, читать про индексы;
2. заплатить специалисту.

сферическому коню в вакууме ни узда ни подковы не нужны... быстрее скакать не будет.

dreamse ©   (01.03.12 07:59)
>Возможно подскажете как еще можно оптимизировать ?

Покажите как сейчас реализовано?
1. тип поля по которому производится поиск;
2. размерность, наличие индексов;
3. Запрос, который выполняет поиск;