ThunderCat

TL;DR: переписывайте базу пока не поздно. Приводите в 3 нормальную форму и будет вам "щастие".

1) Хранение данных по которым идет поиск в таком виде - это сразу расписаться в своей проф. непригодности, никому не показывайте эту стыдобу.

2) Разнесите данные нормально по таблицам, не думайте что вы прям "выкрутились" захерачив все в строку и у вас все в шоколаде. Нифига, теперь у вас по этому полю будут кошмарно тормозные запросы, так как самые медленные операции - это лайк и регексп. Тем более по полю с переменной длинной и без нормальных индексов. И все это вместо суперскоростного индекса по интежер полю.

3) Кроме остальных проблем - теперь вместо просто апдейта поля вам сначала надо его считать, распарсить и только потом обновлять, чтобы не потерять информацию, то есть вы часть стандартной логики бд переносите в код, где ему не место.

4) ну и на одну из проблем вы уже напоролись - поиск по нечетким данным даст нечеткий результат.

group by + order by

PDO?
Вообще как бы у вас там торчат уши от DLE, вы бы в тегах указали что цмс. Смотрите доки по ДЛЕ, как работать с запросами.

если все выбирать одним запросом - юнион и подзапрос:

...
where id not in (
    SELECT `id` 
    FORM `data` 
    ORDER BY date DESC 
    LIMIT 5
    ) 
and `tak` = 12

ini_set('error_reporting',E_ALL);
ini_set('display_errors', 1);
var_dump($_POST);
var_dump($data);

во первых таблицы покажите,
во вторых - пропишите джоины нормально, тогда никаких лишних сторк не будет и без груп бай
в третьих сортировку нужно делать по дате, а не по айди

Никак. Нельзя хранить теги текстовым полем с записанными подряд тегами. Для этого делают связь многие-ко-многим, где теги в отдельной таблице, записи отдельно и есть таблица связей тегов к записям.

селект имя, сум(часы) часы
фром имена и
лефт джоин тайм т
он и.ид = т.емплои_ид
груп бай т.емплои_ид
ордер бай часы деск лимит 3

как то так...

Наиболее затратное по времени выполнения это расчет остатков за весь период на указанную дату в разрезе по номенклатуре.

1) Это ваше предположение или вы делали замеры производительности запросов и кода?
2) Если производительность действительно проседает, то каким образом у вас происходит вычисление? SQL с агрегацией и каунтом?
3) Сколько строк в таблицах выборки?
4) Что показывает explain?
5) Индексы?

Если оптимизировать по выборкам не получается и все упирается в запрос, то можно конечно выводить суммы помесячно, а затем делать агрегацию по суммам + довыборку из неполных месяцев, но тут есть свои нюансы, помимо очевидного усложнения кода и денормализации, как минимум не всегда все обороты намертво приколочены к концу месяца и могут меняться задним числом, что тоже надо будет учитывать и пересчитывать итоги при внесении таких правок.

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

пипец, ну почему всегда одно и то же...

Создаете переменную (строковую) с вашим запросом. Выводите. Смотрите. Если сразу не понятно где накосячили - копируете и вставляете в пхпмайадмин ручками. Смотрите. Если все работает - проблема скорее всего в подключении, если нет - смотрим в чем ошибка.

В любом случае проверяем логи или включаем вывод ошибок.

это чисто примерный запрос, но т.к. я в sql полный профан, прошу объяснить что в нем неверного.

Подскажите как можно снизить нагрузку и увеличить скорость запросов при условии оптимизированного кода и запросов.

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