Akina

Мне нужно найти запись на который у пользователя где у пользователя 1 накопится допустим 30 баллов, это запись id=5.

WITH cte AS (
    SELECT *, SUM(point) OVER (ORDER BY point_lifetime) cum_sum
    FROM tablename
    WHERE user_id = 1 --   у пользователя 1 
    )
SELECT *
FROM cte
WHERE cum_sum >= 30   --   накопится 30 баллов
ORDER BY point_lifetime LIMIT 1;

PS. Поскольку значения в point_lifetime неуникальны, то однозначного решения может и не быть. Во всяком случае до тех пор, пока не будет точно определён порядок записей при равенстве значений этого поля.

SELECT id, MIN(type) type
FROM t1
WHERE type IN (1, 2)
GROUP BY id

LIKE в принципе не пригоден для указанной операции. Это чисто текстовый оператор. В частности, он безусловно применяет к обоим операндам регистронезависимый collation - в этих условиях сравнение БИНАРНЫХ строк способно давать весьма неожиданные эффекты.

Если надо работать именно с бинарными строками - всё плохо. В MySQL нет нормальных функций для работы с ними.

Для решения задачи рекомендую преобразовать бинарную строку в шестнадцатеричное представление, укоротить до 40-символьного (что соответствует 20-байтовому бинарному значению), преобразовать обратно, и сравнить.

WHERE CONV(LEFT(HEX('$entered_hash'), 40), 16, 10) = correct_hash

К тому же такое условие SARGable.

PS. В выражении

WHERE '{value1}' = '{value2}' OR '{value1}' LIKE '{value2}%'

первое условие заведомо лишнее (ведь если оно выполняется, то и второе тоже выполняется).

После сохранения значения в таблице MySQL оно имеет тип того поля, в которое сохраняется, вся история потеряна, какой код и с каким флагами выполнял вставку, ни на что не влияет. Потому при выборке ну никак не может прийти другой тип данных именно от MySQL.

То есть какие-то дополнительные преобразования, изменяющие тип данных, выполняет PHP уже после того, как он получил ответ от MySQL. Или не PHP, а коннектор, который PHP использует для доступа к MySQL. Но в любом случае это происходит уже на стороне клиента.

Предположу, что эмуляция - процесс двусторонний. То есть не только на пути "туда", но и на обратном пути. Что при дополнительной обработке, которую требует настройка PDO::ATTR_EMULATE_PREPARES => true, корёжит тип данных.

На всякий случай проверьте, не вызывает ли изменение этого флага корректировки других флагов. В частности, PDO::ATTR_STRINGIFY_FETCHES.

Как составить ассоциацию squelize один к одному?

В MySQL связи "один к одному" не существует в принципе. Точнее, такая связь нереализуема на изменяемом наборе данных. Неважно, напрямую или через какой-либо ORM, включая и Sequelize.

Возможна только реализация связи "один к (ноль либо один)".

WITH 
cte AS (
    SELECT * , 
           ROW_NUMBER() OVER (ORDER BY `date` DESC, id DESC) rn, 
           DENSE_RANK() OVER (ORDER BY `date` DESC, id DESC) dr
    FROM `list` 
    WHERE user='1' 
    )
SELECT *
FROM cte
WHERE dr <= (
    SELECT dr
    FROM cte
    WHERE rn = 25
    )

Версия сервера: 5.6.51 - MySQL Community Server (GPL)

SELECT *
FROM `list`
WHERE user='1' 
  AND `date` >= (
    SELECT `date`
    FROM 'list'
    WHERE user='1' 
    ORDER BY `date` DESC, id DESC LIMIT 24, 1
)

Если значение поля с типом TIMESTAMP некорректно (а пустая строка - это некорректное значение) - надо заменить его на корректное.

• Если поле NULLable - то например на NULL.
  
• Если настройки допускают нулевую дату - то на `0000-00-00 00:00:00`.
  
• Иначе - на некое предопределённое значение. В зависимости от смысла поля - либо в далёком прошлом, либо в столь же далёком будущем.
  

Два LEFT JOIN, условие связывания - по id и определённому значению типа.

А решение было близко... раз нужны данные с разных уровней группировки, то либо вертеть подзапросы/CTE, либо использовать оконные функции. Как по мне, второе проще.

SELECT DISTINCT
       product_id,
       size,
       SUM(orders) OVER (PARTITION BY product_id, warehouse_id, size) AS orders,
       FIRST_VALUE(stocks) OVER (PARTITION BY product_id, warehouse_id, size 
                                 ORDER BY `date` DESC) AS stocks,
       warehouse_id
FROM stats
WHERE DATE(`date`) >= '2023-09-01' 
  AND DATE(`date`) <= '2023-09-04';

fiddle

Данные поступают на один из серверов кластера. Оттуда они распространяются/реплицируются на остальные серверы кластера. Очевидно, что процесс передачи на другие серверы - не мгновенный, и требует некоторого времени. И столь же очевидно, что если после получения новых данных, но до передачи их в другие серверы кластера исходный сервер сдох, то этих данных не будет на оставшихся серверах, и, как Вы правильно заметили, запросы будут выполняться с устаревшими данными.

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

При добавлении набора данных в связанные таблицы (а по большому счёту - вообще всегда) следует забыть о существовании INSERT .. VALUES и пользоваться исключительно INSERT .. SELECT. Первый запрос вставляет запись в основную таблицу, второй вставляет в зависимую, получая необходимое для связывания значение из основной по известным критериям отбора (по только что вставленным значениям, либо, в случае MySQL, из LAST_INSERT_ID).

Демонстрация метода замены вставки на обновление: fiddle.