Руслан .

Можно найти ближайшие к началу периода пн и вс. А дальше с помощью date_add прибавлять к ним по 1 неделе пока одна из дат не вылетит за дальнюю границу вашего диапазона

Может индекс поменять с product_id+prop_id на
prop_id + product_id. Отбор же по prop_id идет, а тут не попадание в первое поле индекса.

Возможно вам подойдёт CTE, вот тут посмотреть можно
https://dev.mysql.com/doc/refman/8.0/en/with.html

Можно попробовать конструкцию EXISTS.
Как-то так:

SELECT
    tt.`email`,
    COUNT(tt.`email`) AS `count`
  FROM
    `e_stat` AS tt
  WHERE NOT EXISTS (
      SELECT 1
        FROM `e_stat`
        JOIN `pb`
          ON `pb`.`e_stat_id`  = `e_stat`.`id`
       WHERE `e_stat`.`msg`   = '68'
         AND `e_stat`.`email` =  tt.`email`) 
       GROUP BY tt.`email`

Можно попробовать сделать небольшую нормализации, например перенести из таблицы task три поля ( type, provider, cat ) в отдельную таблицу tasktype, а в исходной таблице оставить только одно поле tasktypeID и это поле поместить в индекс таблицы task вместо предыдущих трех.
Т.к. у вас запросе условия указаты статичными, то можно вначале наиграть tasktypeID по таблице tasktype, которая не должна быть очень большой и затем идти в индекс от task по двум полям вместо четырёх. Кроме этого индекс в task станет меньше места занимать и это должно ускорить поиск по индексу и его перестраивание при добавлении новых строк.

Вот тут немного странно сделано:
DB::beginTransaction();
$waitingPayment = HistoryPayment::find($waitingPayment->id);
if ($waitingPayment->status_transaction === 'success') {
return false;
}

Открываем транзакцию, чекаем что status_transaction === 'success' и выходим не закрывая её и не откатывая. Может вынести проверку до открытия транзакции.
Просто открытая тут транзакция может, где-то далее не явно использоваться и возможно влиять на то, что что-то потом откатывается при rollback, что не должно откатывать я.

Есть ещё вызов
ChangeBalance::dispatch($user->id, $user->balance);
Он за пределами основной транзакции и не в try, может он влиять на баланс, например если внутри у него ошибка случается?

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

Так как данные грузятся раз в 3-4 дня, наверное не очень критично, что загрузка будет выполнять не мгновенно. Тут наверное проще в несколько этапов сделать: на первом проходе построить список идентификатор датчиков по которым значение не поменялось, затем по этому списку проапдейтить дату окончания интервала на дату текущей загрузки, затем по датчикам которые не попали в список перелить строки в архивную таблицу и наконец поменять для изменённый датчиков в оперативной таблице значение счётчика и даты начала и окончания интервала.
Всё шаги можно делать массово.

Используйте для передачи параметров в запрос технику описанную вот тут:
https://www.w3schools.com/php/php_mysql_prepared_s...

В таблице user есть поле auth_key. Для этого поля не задано значения в вашем коде INSERT INTO и не задано значения по умолчанию при создании таблицы. Отсюда и ошибка.

Можно дать пользователю возможность в интерфейсе выбрать поля для сортировки и направление сортировки (ASC/DESC) и хранить в итоге для пользователя только сформированную секцию ORDER BY.

Возможно по типу = 14 выдается очень много строк, посмотрите на такую статистику:

SELECT bls.idstatus, COUNT(1)
FROM
    SS_B2POS.blank_last_status AS bls
        LEFT JOIN
    SS_B2POS.blanks AS b ON b.idblank = bls.idblank
        LEFT JOIN
    SS_B2POS.clients AS c ON b.idclient = c.idclient
GROUP BY bls.idstatus;

Можно так попробовать:

DELETE posts
  FROM posts pp
 WHERE EXISTS(SELECT 1
                FROM posts pm
               WHERE pm.authorid = pp.authorid
                 AND pm.id       < pp.id)

По каждому автору authorid удаляем все сообщения для которых можем найти предыдущее сообщение pm.id < pp.id, таким образом по каждому автору останется только первое сообщение.
Порядок следования сообщений равен порядку увеличения posts.id, если это не так, то вставьте свой критерий.

Похоже вот тут ошибка:

$user = $db->query("SELECT (id, pName, pPassword) FROM users WHERE pName = '$nick'");
нужно так:
$user = $db->query("SELECT (id, pName, pPassword) FROM users WHERE pName = '" . $nick . "'");

А так переменная $nick в запрос как имя переменной подставляется, а не как значение.

Можно так попробовать:

select en.Name
  from empl_services es
 inner join services ss
         on ss.id     = es.services_id
        and ss.title in ('Крутит гайки', 'Гнёт арматуру')
 inner join employee em
         on ss.id     = es.employee_id
 group by en.Name
having count(1) = 2