Макс

посмотрите на mailpiler
там письма хранятся в файлах, но поиск по ним реализован через sphinx.

ИМХО тянуть ингредиенты из таблиц - устанете заполнять рецепт. Оно конечно правильно с академической точки зрения, но с реальной даст профит пожалуй только в том, что ингредиенты будут везде называться одинаково. Зато если планируете давать пользователю заводить рецепт - как заводить новый ингредиент? А если дать это пользователю - в результате 100% получите 20 вариантов майонезов.

столько не потянет и оракл. смотрите на хадуп

вместо ORDER BY xxx
ORDER BY CAST(xxx AS SIGNED)
или ORDER BY xxx+0

(int)$id_order в одиночные кавычки возьмите

Transact-SQL существует только для Microsoft SQL Server?

да, это диалект microsoft.
в примере на первый взгляд ничего не реализуемого на MySQL нет. Или на Postgre(что вероятнее).
MSSQL в версии Express бесплатен, при этом полностью поддерживает T-SQL. Если поиграться, то и его хватит. Если что-то серьезное - можно и купить.

ну так NULL - это не значение, это отсутствие значения. Как вариант - вытянуть данные во временную табличку и заменить NULL на что-то значащее перед группировкой.

крайне странный выбор тегов для вопроса.... при чем здесь MSSQL и MySQL?
по делу - как вызываете функцию?

куда пытаетесь выводить?

По MySQL недавно на youtube нашел курс от УЦ Специалист. Мне очень понравилось. Вот прямо с азов - и до основ оптимизации. И лектор хорош.

идентифицируйте по куки. в БД пишите ID из куки, datetime голоса. при формировании страницы проверяйте, был ли уже сегодня голос от этого ID.

сразу отмечу - это защита "от пионеров". куки лежат на стороне клиента, ничто не мешает ему их стереть. Более надежно авторизация.

[OK] Query cache efficiency: 29.6% (17M cached / 57M selects)
[!!] Query cache prunes per day: 91403

- на вскидку. кеш запросов не эффективен. Наверное много апдейтов в таблицах.
в кеш попадает всего 29,6% запросов, а вот очисток кеша за день 91К.

ну и индексы - каждый третий запрос без индекса.
всего Query cache efficiency: 29.6% (17M cached / 57M selects) - 57 млн запросов
из них без индексов Joins performed without indexes: 20 729 886 - почти 21 млн.
вообще при Ваших объемах

[--] Data in MyISAM tables: 838M (Tables: 1133)
[--] Data in InnoDB tables: 277M (Tables: 483)

и объеме памяти все должно летать - все влезает в память несколько раз.

а можно по-подробнее про цель действа? Может проще сделать правльный SQL запрос (что-то мне подсказывает, что тут попахивает JOINом)?

И завязывайте с mysql_query. оно скоро умрет.

PS выполнят второй запрос в консоли mysql пробовали? может у вас нет ни одной записи в user с id = 1

инструкция.
Или я Вас неправильно понял, и Вас беспокоит именно даунтайм при первоначальной синхронизации?

1. нет, не правильно.
блокировка либо READ, либо WRITE.
MySQL.
READ - все(как сам процесс, так и другие) могут только читать.
WRITE - процесс, который вызвал блокировку, может читать и писать, остальные курят.
2. попробовать из другой сессии произвести запрещенное действие (INSERT/UPDATE/DELETE для READ, что угодно для WRITE) - запрос "зависнет" до разблокировки. Или до таймаута.
3. Будет ждать до таймаута.