alexalexes

Вариант для MySQL ниже 8 версии:

select A.*
from 
(
SELECT d.id AS dialog_id, 
       d.date_latest_message,
       (select max(DM.added_date)
           from dialog_messages dm3
          where dm3.dialog_id = dm.dialog_id
       ) as datetime_latest_message,
       Dm.Id as Dm_Id,
       DM.message,
       DM.added_date
  FROM dialogs d
  join dialog_messages dm on DM.dialog_id = D.dialog_id
  WHERE (select count(*)
           from dialog_messages dm2
          where dm2.dialog_id = dm.dialog_id
          and dm2.id > dm.id -- по идент. будет эффективнее работать, чем по дате-время, к тому же первичный ключ, как правило, проиндексирован, не требуется доп. индексов
        ) < 3 -- берем только те сообщения, которые позднее опубликованы чем текущее (3 вышестоящих)
    and DATE(d.date_latest_message BETWEEN) '2020-10-01' AND '2021-10-08'
) A
order by A.datetime_latest_message desc, A.Dm_Id desc

Если MySQL версии 8 и выше, как вариант, можно взять оконную функцию row_number.

select A.*
from
(
  SELECT 
         d.id AS dialog_id, 
         d.date_latest_message,
         (select max(DM.added_date)
           from dialog_messages dm3
          where dm3.dialog_id = dm.dialog_id
         ) as datetime_latest_message,
         Dm.Id as Dm_Id,
         DM.message,
         DM.added_date AS message_added_date,
         row_number() over (partition by d.id              -- окно счетчика в пределах идент. диалога
                            order by DM.Id desc    -- направление сортировки счетчика
                           ) dm_rownum -- счетчик для отсечения порций
  FROM dialogs d
  join dialog_messages dm on DM.dialog_id = D.dialog_id
  WHERE DATE(d.date_latest_message) BETWEEN '2020-10-01' AND '2021-10-08'
) A
where A.dm_rownum <= 3 -- отсекаем нужное число "локальных" отсчетов
ORDER BY A.datetime_latest_message DESC, A.Dm_Id DESC

Этим запросом крайне внимательно изучаете - удовлетворяет ли вас результат преобразования строк в result_mod_f1 из mod_f1, и result_mod_f2 из mod_f2.

select mod_f1,  replace(mod_f1, '.png', '.webp') as result_mod_f1,
          mod_f2,  replace(mod_f2, '.png', '.webp') as result_mod_f2
from table

Если что-то не устраивает, переписываете replace-ы.
Если что-то переписали, то заменяете выражения в правых частях после знака =, чтобы преобразование mod_f1 соответствовало mod_f1, а преобразование mod_f2 для mod_f2.

/*update table
set mod_f1 = replace(mod_f1, '.png', '.webp'),
      mod_f2 = replace(mod_f2, '.png', '.webp')*/

Снимаете комментарий, словно собираетесь открыть защитную крышку на красной кнопке атомной бомбы и выполняете запрос.
ПС: Желательно делать это в программном средстве, которое поддерживает режим незакрытой транзакции, чтобы можно было откатить.
ППС: Если таблица очень большая, то лучше обновлять порциями.

/*update table
set mod_f1 = replace(mod_f1, '.png', '.webp'),
      mod_f2 = replace(mod_f2, '.png', '.webp')
where mod_f1 like '%.png%'
      or mod_f2 like '%.png%'
LIMIT 1000 */

1. Ограничьте количество предметов в корзине каким-то макс. значением, оно должно быть явно задано, но не вызывало дискомфорта у пользователей (оно должно иметь такое значение, чтобы в нормальных человеческих условиях оно едва достижимо).

$max_cart_item_count = 500;
$curr_cart_item_count = min(count($_SESSION['cart']), $max_cart_item_count);
for($i = 0; $i < $curr_cart_item_count; $i++)
....

2. Есть опасность применения SQL инъекций.
В этом месте, где подставляется переменная в текст запроса, если умело закомментировать кавычку, то можно получить полный доступ к базе.
WHERE `type`= '$id'
Избегайте подставлять любые переменные с пользовательскими данными в текст запроса ("с пользовательскими данными" и "в текст запроса" - нужно подчеркнуть и осмыслить как отдельные понятия с точки зрения безопасности). Для этого существует специальные методики подготовки запроса:

$stmt = $conn->stmt_init();
$stmt->prepare("SELECT * FROM `items` WHERE `type` = ?"); // подставляем текст запроса, причем на месте входных параметров ставим специальные маркеры - плейсхолдеры.
$stmt->bind_param("i",  $id); // подставляем на место плейсхолдера значение параметра как целочисленный тип
$stmt->execute(); // вот теперь можно выполнить запрос
$result = $stmt->get_result();
while($row = $result->fetch_assoc())
{
 // Обработка результатов
}

Как выглядит ваша проблема:
Таблица новостей:
ID, CATEGORIES
1, '1,13,14'

Как нужно реализовать:
Добавить еще таблицу Categories_Of_News
ID, NEWS_ID, CATEGORY_ID
1, 1, 1
2, 1, 13
3, 1, 14

Тогда запросы не будут содержать никаких костылей с парсингом строк и у вас будут работать индексы (если их создать).
Например, получить все категории, в которые входит новость :news_id

select  C.Id
from News N
join Categories_Of_News CoN on CoN.News_Id = N.Id
join Category C on C.Id = CoN.Category_Id 
where N.Id = :news_id

PS: Смотрите, как реализовать связь "многим-ко-многим".

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

update `table` set атрибут_не_первичный_ключ = 1
where id in (1, 2, 4, 10);

Другое дело, если это касается атрибутов с уникальным свойством.
Если нужно сделать рокировку значений, то поскольку первичный ключ имеет свойство уникального значения, то нужно действовать в два этапа.
1. Переписать id-шники интересуемых строк так, чтобы новый id был за диапазоном присваиваемых id.
Можно переписать в большую сторону, если у вас максимальное число записей пару тысяч, то воспользоваться новыми значениями, например, от миллиона.
Но проблема в том, что если система не остановлена во время этой рокировки, то вероятно, вставка новых строк будет происходить с присвоением макс. последнего значения +1, тогда новые строки окажутся с миллионными id-шками.
Нужно взять диапазон отрицательных чисел в качестве промежуточного состояния рокировки id.

update table
set id = case
   when id = 1 then -1
   when id = 2 then -2
   when id = 4 then -4
   when id = 10 then -10
   else id -- страховка от дурака, если неправильно описан in 
end
where id in (1, 2, 4, 10)

2. Второй шаг заключается в том, чтобы переписать нашим отрицательным id новые положительные значения, чтобы каждая строка получила новые значения 1,2,4,10. Например, можно поменять местами id соседей.

update table
set id = case
   when id = -1 then 2
   when id = -2 then 4
   when id = -4 then 10
   when id = -10 then 1
   else id -- страховка от дурака, если неправильно описан in 
end
where id in (-1, -2, -4, -10)

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

Если вы понимаете, что делает этот запрос:

UPDATE article SET visits=(visits+1) WHERE id='".$theme_idss."' LIMIT 1

То по аналогии можно плюсовать интересуемый столбец:

UPDATE article
SET visits=(visits+1),
      today = today + 1 -- суточные посещения
 WHERE id='".$theme_idss."' -- когда разберетесь, что такое sql-инъекция, то перепишите все запросы, использующие такой стиль подстановки параметров (склеиванием строк)
LIMIT 1 -- после того, как разберетесь, является ли id первичным ключом, можно убрать лимит

Но при добавлении столбца нужно позаботиться, чтобы у столбца значение по умолчанию было 0.

ALTER TABLE article
ADD COLUMN today int default 0 AFTER visits

В скрипте, который чистит таблицу раз в сутки предусмотрите запрос, обнуляющий суточный счетчик у всех статей:

UPDATE article
SET today = 0

PS: Если хотите анализировать посещаемость, то лучше воспользоваться готовыми счетчиками от поисковых систем - Google Analytics или Яндекс-метрики.
Если хотите все же использовать свой лог, то лучше его не удалять. Вдруг захотите выявить среднемесячное/суточное/годовое посещение или в каком то другом разрезе по разным разделам сайта. Для пересчета понадобится каждая запись посещения.

Вы этой таблицей кодируете граф (не важно чего).
Если принимаете за правило, что каждая запись кодирует ребро графа только в одном направлении (граф является направленным), то, чтобы добавить другое направление, тогда вам нужно вставить еще одну запись.
Например, существует ребро от вершины 1885 до вершины 4683, чтобы прописать ребро с обратным направлением, нужно вставить запись (4683, 1885).
Список ребер к присоединенным вершинам от данной вершины достаточно выбирать таким запросом:

select * from t
where t.idProduct = :id_product and t.relatedProduct <> :id_product -- сравнение с <> исключает петлю на собственной вершине

Если у вас граф ненаправленный, то можно обойтись одной записью. При получении выборки (ребер графа) вам нужно выбирать не только ребра от вершины idProduct до relatedProduct, но включать те записи, ребра которые прописаны от relatedProduct до idProduct.
Скорее всего запрос будет иметь такой вид:

select * from t
where (    (t.idProduct = :id_product and t.relatedProduct <> :id_product) -- сравнение с <> исключает петлю на собственной вершине
            or (t.relatedProduct = :id_product and t.idProduct <> :id_product))

Но обязательно нужно определиться, работает ли совместимость товаров в обе стороны, от этого зависит выбор типа графа и правила его чтения/записи.

Чтобы найти читателей с последними взятыми книгами, нужно при помощи оконной функции row_number пронумеровать строки в пределах каждого читателя (задав партицию по айди читателя) в порядке убывания по дате taken_at. Из полученного результата взять строки, которые получили номера 1.

select * from
(select r.id as reader_id, r.first_name, r.last_name, b.id book_id, b.name, b.pub_date, row_number() over (partition by r.id order by l.taken_at desc) as rownum
from readers r
left join log_taking l on r.id = l.reader_id
left join books b on b.id = l.book_id
) a
where a.rownum = 1

PS: Связка left join выведет всех читателей, в независимости, брали они книги или нет. Просто join даст список читателей, которые брали книги хоть один раз.
PPS: Оконные функции доступны с MySQL версии 8.
Если версия 5, то придется городить велосипед с пользовательскими переменными.

Правильно построить выборку из нужных таблиц.

INSERT into archive (title_product, title_category, price_product) 
SELECT p.title, c.title, p.price
  from product p
   join category c on p.category_id = c.id

Это делается апдейтом с подзапросами.

update table tb
      set tb.type_id = (select tp.id from types tp where tp.name = tb.type_name limit 1) -- выбираем подзапросом id из справочника по совпадению наименования поля в обновляемой таблице
 where tb.type_id is null -- страховка, что будем обновлять не установленные значения
     and exists(select 1 from types tp where tp.name = tb.type_name) -- будем ставить ключ, если есть наименование в справочнике types

PS: Прежде чем выполнять update, убедитесь при помощи select с тем же where, что вы вставите нужные для вас значения в поля секции set. По принципу поговорки: "Семь раз select-ни - один раз update-ни".
PPS: Желательно, избегать ситуаций, когда вам периодически нужно нормализовывать структуру данных, в идеале, при insert-е нужно сразу определять ключик, а поле наименования использовать только тогда, когда нужного наименования нет в справочнике.