Странное поведение таблицы отчета

[mailarn]

Все началось с обновлении Р с версии 3.6.1 до версии 3.7.2
После обновления обнаружилось, что на хостинге стоит версия mySQL 5.7 и она уже не подходит то техническим требованиям. Пришлось просить техподдержку перенести аккаунт хостинга на сервер с версией mySQL 8+

В Руководителе был сделан отчет (Дополнение - Отчеты - Общие отчеты) который делает выборку из сущности только "завтрашние" даты.
После смены версии mySQL строки в таблице отчета начали дублироваться, т.е. одна и та же запись могла быть 2 раза. Но самое страшное, что это да же не дублирование, а строка которая появлялась дублем заменяла собой другую запись т.е. какая то строка не отображалась в отчете, но вместо нее появлялась строка дубль так как количество записей которые отображаются внизу таблицы было всегда одно и то же.

На скриншотах видно, что одна и та же запись присутствует на первой странице отчета и на второй.

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

Я уже полностью переделывал отчет, все проверял - ни чего не помогает.

Кто ни будь встречал подобное? И как это исправить...

[mailarn]

Развернул тестовую установку этого же шаблона на другом сервере где база данных MariaDB 11.6
Проблем с дублированием строк нет, все работает отлично.
Вывод один - Руководитель не полностью поддерживает mySql 8+

[mailarn]

Если кому интересно, проблема решена путем переноса CRM на хостинг с установленной БД MariaDB 11.6.
С базой данных MySQL 8+ Руководитель, на данный момент в версии 3.7.2, корректно работать не будет.

Не много теории:
Причина в нестабильной сортировке (non-deterministic ORDER BY) при пагинации. MySQL 8.0 изменил поведение сортировки по сравнению с 5.7 при неуникальных значениях в поле ORDER BY.

В отчёте используется ORDER BY только по полю дата_доставки. Если у нескольких записей одинаковая дата (например, несколько доставок на одно и то же число), MySQL не гарантирует, в каком порядке эти записи будут идти между собой.

В MySQL 5.7 / MariaDB это работало "более-менее предсказуемо" - записи возвращались в порядке вставки (физическом порядке на диске).
В MySQL 8.0 механизм хранения и выборки изменился (InnoDB), и при одинаковых значениях в ORDER BY движок может возвращать записи в разном порядке при каждом запросе.

При повторном вызове (для следующей страницы OFFSET 50) MySQL 8.0 может перетасовать записи с одинаковой датой. В результате запись, которая была на 49-й позиции, при следующем запросе оказывается на 52-й позиции и попадает уже на вторую страницу.
Итог: одна запись видна на двух страницах, а какая-то другая нигде.

Общее количество записей при этом считается корректно, это просто COUNT(*), он не зависит от порядка.

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

Это касается сортировки выборки записей их любых сущностей или при построении отчетов.

[Fait]

Если кому интересно, проблема решена путем переноса CRM на хостинг с установленной БД MariaDB 11.6.
С базой данных MySQL 8+ Руководитель, на данный момент в версии 3.7.2, корректно работать не будет.

Не много теории:
Причина в нестабильной сортировке (non-deterministic ORDER BY) при пагинации. MySQL 8.0 изменил поведение сортировки по сравнению с 5.7 при неуникальных значениях в поле ORDER BY.

В отчёте используется ORDER BY только по полю дата_доставки. Если у нескольких записей одинаковая дата (например, несколько доставок на одно и то же число), MySQL не гарантирует, в каком порядке эти записи будут идти между собой.

В MySQL 5.7 / MariaDB это работало "более-менее предсказуемо" - записи возвращались в порядке вставки (физическом порядке на диске).
В MySQL 8.0 механизм хранения и выборки изменился (InnoDB), и при одинаковых значениях в ORDER BY движок может возвращать записи в разном порядке при каждом запросе.

При повторном вызове (для следующей страницы OFFSET 50) MySQL 8.0 может перетасовать записи с одинаковой датой. В результате запись, которая была на 49-й позиции, при следующем запросе оказывается на 52-й позиции и попадает уже на вторую страницу.
Итог: одна запись видна на двух страницах, а какая-то другая нигде.

Общее количество записей при этом считается корректно, это просто COUNT(*), он не зависит от порядка.

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

Это касается сортировки выборки записей их любых сущностей или при построении отчетов.

Ещё от себя добавлю - на MySQL убрали кэширование запросов, из-за чего CRM после переезда на них начинает жёстко тормозить, и приходится мудрить с индексами, оптимизацией ( убирать все а-ля select * ...)