egorinsk

Явно в приложении увеличивать счетчики. В MySQL это можно делать одним запросом вроде:

INSERT INTO hourly_table() VALUES() ON DUPLICATE KEY UPDATE x = x + ?, y = y +?
INSERT INTO daily_table() VALUES() ON DUPLICATE KEY UPDATE x = x + ?, y = y +?

Правильное, но невыгодное финансово решение: не нанимать быдлокодеров и переделать сайт.

Быстрое и дешевое решение: написать/прикрутить фильтр, который не будет пропускать запросы со словами SELECT, where, JOIN, UNION (в любом регистре), script, onload, onerror, onmouseover (и все остальные JS-события), object, applet, iframe, frame и так далее. Список слов ищите в интернете. Если ваши посетители, например. общаются на русском, очевидно, такие слова они вряд ли используют.

Также, можно заменять во входных данных одиночную, двойную кавычки и апостроф на косые юникодные кавычки. Выглядят они примерно так же, а инъекцию уже не сделать. Также можно использовать прием Дурова — в словах вроде script менять с на русскую — выглядит оно так же, а вреда никакого не несет. Сайт работает, а инъекции — нет, школохакеры мучительно пялятся в монитор, а поделать ничего не могут.

Также, если вы умеете администрировать linux, можно на сервере засунуть веб-сервер и сервер БД в отдельные контейнеры и изолировать их (или даже selinux включить). Плюс зафаерволлить намертво. Это вообще идеальнй вариант — даже если ваш сайт представляет один большой бекдор, взломщик не сможет получить из него никакой выгоды. Если правильно настроить сервер, фаерволл и изоляцию, для написания кода можно нанимать хоть школьников.

EXPLAIN пользоваться умеете? Мониторинг и запись в лог медленных запросов настроили? Памяти достаточно выделили?

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

Прежде чем гадать, проанализировали бы выполнения запроса, и посмотрели, что именно так долго делается. Может, у вас тормозит не обновление, а поиск и просто индекса по полю uid не хватает?

Есть официальный список под названием КЛАДР, выпускается госструктурами, скачивается бесплатно, БД в формате FoxPro (допотопная досовская СУБД) открывается либо OpenOffice, либо в PHP через какое-то расширение, которого нет под Windows и котрое надо руками компилировать.

Вариант 2 — если вам надо часто добавлять поля, то учтите, что добавление поля — это фактически создание второй копии таблицы (т.е. долго). Также, при большом числе полей растет объем таблицы, ухудшается время доступа.

Что касается вариата 1, рассмотрите также вариант выбирать записи без JOIN, а 2 запросами — MySQL на джойнах может неэффективно работать (к сожалению, точнее сказать не могу, это надо проверять на практике).

Я бы лично сделал вариант 1, но с кешированием в каком нибудь key-value storage.

SELECt fields FROM table WHERE option_id IN (1,2) UNION SELECT fields FROM table WHERE object_id IN (1,2)

Такой подход позволит использовать индексы (если они есть) вместо перебора всех строк таблицы (при использовании OR)

А что непроизводительного в LIKE something%? Индекс же используется.

Если надо запретить создание товаров с одинаковыми именами, надо сделать UNIQUE INDEX по полю name_goods. Чтобы индекс не стал огромным уродливым тормозящим монстром, его надо объявлять примерно так (ограничить размер индексируемой подстроки):

ALTER TABLE im_goods ADD UNIQUE INDEX ix_name ( name_goods(10) );

Тогда БД не позволит вам вставлять 2 товара с одинаковым названием (смотрите, чтобы это не было потом сюрпризом).

Хотя, может, я вас не так понял.

P.S. Советую также в следующий раз правильно называть поля, чтобы не коробило глаза понимающих английский: товар = product, название = product_name, ид товара = product_id, рубрика = category. Вдруг будете для американцев например делать магазин, пригодится.