alexalexes

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-е нужно сразу определять ключик, а поле наименования использовать только тогда, когда нужного наименования нет в справочнике.

Если просто нужен флаг, что товар в корзине, то достаточно этого запроса.

SELECT p.*,
            case
               when exists(SELECT 1 from cart c where c.products_id = p.id)
               then 1
               else 0
            end is_exists_in_cart -- есть товар к корзине? 0 - нет, 1 - есть
FROM table_products p

Если нужны параметры товара, а не только его наличие, то как минимум будет такая конструкция:

SELECT p.*, c.*
FROM table_products p
left join cart c on c.products_id = p.id

PS: Конструкция запроса может сильно меняться от того, какие свойства вам нужно извлечь, чтобы вывести в итоговую выборку.