ThunderCat

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

как то так...

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

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

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

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

trigger

Как вариант я думал написать говнокод, который на PHP преобразует первоначальную дату диапазона из 26.05.2020 в "2020-05-26 00:00:00" а конечную дату в "2020-05-27 23:59:59" а потом сравнивать, но помоему это какая-то дичь.

То есть по вашему преобразовывать ВСЕ строки таблицы для сравнения в формат НЕ ПОДДЕРЖИВАЕМЫЙ интерфейсом бд это ок, а 2 значения привести в стандарт - не комильфо...

Обратите внимание на ответ Rsa97, Даты сравниваются как строки, по этому и сравнение идет именно в таком формате, от года к дате. Ваше преобразование делает строки вывернутыми по смыслу, то есть сортировка идет по дате дня, год "как бы вообще не учитывается".

сессия хранит только элементарные типы, представляемые в виде строк. Что логично, ибо это суть файл, либо аналогичное хранилище. Для того чтобы работала подобная магия нужно:
а) удалить из объекта все ссылки на ресурсы, которые будут мешать сериализации, если таковые имеются
б) сериализовать объект и записать в сессию

и в обратном порядке для чтения:
а) Загрузить класс объекта который вы будете получать (иначе магии не получится)
б) Десериализовать из сессии и добавить в объект все ссылки на нужные ресурсы, например ссылку на объект бд.

concat, group_concat, хотя понятно что это все кривые решения и по уму с самого начала у вас должно все это хранится как многие ко многим.

используйте order by field_name desc/asc

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

так же смотрите вот такой ответ или гуглите sql nested sets.

1) Реальной причины вы так и не нашли? Первым делом я бы все же нашел строку на которой режет запись, а потом уже думал что делать. Ну и пробовал запросы с ней руками пробить.
2) Реалэкейп все таки не лучший выход, использование подготовленных выражений уже давно стандарт для работы с бд. Это позволяет не придумывать велосипеды и работать с базой более свободно.

А чего вы хотели? Для этого и делают датетайм, то есть налицо ошибка в проектировании структуры данных.
Единственное решение будет построить запрос разбив время на два интервала, то есть в логике определяете если диапазон прыгает через 0 и бьете на 2 интервала,

SELECT * 
FROM tablename 
WHERE 
('01:00:00' BETWEEN '23:00:00' AND '23:59:59') or 
('01:00:00' BETWEEN '00:00:00' AND '02:00:00')