Boris Köln

Все файлы и БД хранить в кодировке UTF-8

Возможные варианты:
- веб-сервер теряет авторизацию (не передает в PHP)
- такой логин-пароль не указаны в БД

Чтобы узнать точнее, надо использовать xdebug или хотя бы в каждый if добавить логирование в файл. А вообще весь этот код надо выкинуть и написать в нуля правильно.

Сначала выбрать юзеров и неделю. Потом из предыдущей таблицы выбрать юзеров, у которых количество недель равно количеству недель в исходной таблице

SELECT user_id
FROM (
    SELECT user_id,
           YEARWEEK(datetime, 1) AS year_week,
           COUNT(DISTINCT YEARWEEK(datetime, 1)) AS weeks_count
    FROM your_table
    GROUP BY user_id, YEARWEEK(datetime, 1)
) AS user_weeks
GROUP BY user_id
HAVING COUNT(DISTINCT year_week) = (
    SELECT COUNT(DISTINCT YEARWEEK(datetime, 1)) 
    FROM your_table
);

У каждого варианта свою плюсы и минусы.
Делать кастомизированный API со сложной структурой - экономия миллисекунд на запросе, но усложнение разработки и поддержки.
В общем случае выгоднее использовать стандартные REST или GraphQL. Если объекты связанные (например, заказы и товары в заказах), то делать один запрос, который возвращает многомерный массив. Если объекты несвязанные (каталог товаров и информация о юзере), то разные запросы.

Но столкнулся с тем, что пропускается такое:
Username™

Нет, не пропускает.
https://onlinephp.io/c/75a3f

P.S. Если "i", то "A-Z" лишнее. И круглые скобки в данном случае - тоже.

ДеньВыхода + (КоличествоСерий делить с остатком на Количество(ДнейВыхода)) * 7 + остаток с учетом дней выхода

1. Лочить обрабатываемую строчку.
Для PostrgeSQL - pg_try_advisory_lock() https://www.postgresql.org/docs/9.1/functions-admi...
Для MySQL аналога нет. Другие локи (например, новое поле "в обработке") дают непредсказуемые результаты при "Race condition" https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D1%81%D...

2. вместо БД использовать более подходящие средства - в данном случае "очередь " (например, RabbitMQ)

По указанной ссылке не JSON, а HTML с тегом <pre>

SELECT reltuples FROM pg_class WHERE relname = "table"

Это и есть самый быстрый способ.
Погрешность можно (нужно) уменьшить, если сделать VACUUM или ANALYZE. Подробнее см. https://www.postgresql.org/docs/9.2/row-estimation...

Плохой вариант: использовать lock.
для cron: flock
для mysql: https://dev.mysql.com/doc/refman/8.0/en/lock-table...
для postgresql: https://www.postgresql.org/docs/9.1/functions-admi...

Хороший вариант: полностью переписать с привлечением грамотного разработчика

Цикл по всем занятым диапазонам.
Если занятый диапазон имеет любое пересечение с искомым диапазоном - занято, иначе свободно.

P.S. Еще надо учесть, что время рабочее

Стоит дом на улице, проверяю входную дверь, а там много следов от попыток вскрыть ее фомкой.
Откуда они могут появиться, если я пользуюсь ключом?

https://developer.qiwi.com/

Представь, что сайт - это автомобиль, прямой запуск скриптов - запуск двигателя, а плагин - автокресло.
И сразу поймешь, что за фигня получится при "прямой запуск" "плагина".

Если "максимум по 1 строке", то можно легко сделать с помощью "GROUP BY".

Если "максимум по 2 строки", то уже нужны счетчики, подзапросы или join на себя, всё это гораздо сложнее и делать, и выполнять. Гораздо проще выбирать всё, а дальше на PHP с помощью массива считать количество каждого типа и при необходимости continue

устанавливаю несуществующее поле при запросе в БД

Код в студию. И заодно код, где ты пытаешься это поймать, но почему то не ловится.
В указанном коде ловятся ошибки только в "$client->request('POST', 'test');", но там ошибок и так нет.

Странный вопрос. Вы установили посредника, а потом удивляетесь, почему с ним работает медленнее, чем без него. Очевидно, что часть ресурсов сервера тратится на сам docker.

Лучше переформулировать вопрос, почему на docker тратится так много ресурсов. Но для ответа на этот вопрос лучше нанять опытного админа, который будет ковыряться в вашем сайте, профилировать и искать проблему.

RTFM https://dev.mysql.com/doc/refman/8.0/en/create-tab...