Adamos

Судя по тем возможностям, которые вы приписываете этому страшному хакеру, он уже сидит у вас на сервере. Вряд ли вы сможете как-то от него защититься...

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

Даже без JOIN (мало ли, какие-то данные могут быть многострочными) совершенно необязательно городить циклы.
Вы запросили статьи. Получили данные. Зачем сразу выводить? Соберите их пока в массив, попутно создавая массив id статей, авторов, чего там еще понадобится.
Следующим номером сделайте один (!) запрос - SELECT author_name FROM authors WHERE author_id IN (у нас уже есть этот массив). Аналогичный запрос или два к таблице с комментариями - и все, больше вам базу дергать не требуется, и все данные для вывода получены.

Глядишь, понемногу придет осознание, какую пользу приносит разделение логики и вывода...

REAL описывается не одним размером, а двумя - сколько цифр всего и цифр после точки.
REAL(10,2) - например.
Собственно, для цен логичнее использовать специально для них созданный DECIMAL. С аналогичным описанием.

А что, просто добавить индекс на поле идентификатора товара недостаточно?
Насколько я понимаю, при его наличии запрос на количество строк с таким индексом базу практически не напрягает.
Или я ошибаюсь?

Vidal?

У меня в аналогичной ситуации каждую ночь отрабатывает rsync для файлов и mysqldump для базы. Репликация имеет смысл, только если базы здоровенные и целиком их таскать накладно. Или при необходимости частого обновления.