Михаил Ливач

вместо условных 100 кликов людям засчитывало ~40

судя по sql у тебя количество сохраняемых кликов считается как сначала запросом получить текущее значение, затем сохранить его увеличенным... что естественно неправильно обсчитывается, если одновременно на бакэнд идут несколько запросов, и завершаются в разном порядке (т.е. первый, получил значение 1, затем его обогнал второй, получил то же значение 1, оба отправляют +1 значение, т.е. 2, вместо ожидаемого 3.

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

update set clicks=clicks+1, last_click_time=now() where last_click_time+:ALLOWED_CLICK_INTERVAL<now() and id=:current_id

p.s. даже очень слабая машина позволит делать сотню запросов в секунду на обновление, а хорошая - десяток тысяч

Можно больше, но тогда понадобится разнести таблицу аналитики и таблицу событий, в таблицу событий записывают события, но она без индексов, а в аналитику зааливать данные из всех собранных событий, в цикле

Судя по предоставленным данным, от поставщика некий артикул всегда находится в конце строки.

Регулярные выражения тут не нужны.

Предлагаю просто отформатировать ответ от поставщика и вывести пересечения

$items = array_intersect(
    $companyItems, // на сайте
    array_map(
        function (string $item) {
            $parts = explode(' ', $item);
            return end($parts);
        },
        $supplierItems // от поставщика
    ),
);

Проверка

У меня был проект с такой задачей (и тоже ресторанный). Особенностей у него три:

• "магазины" могут закрываться, а набор товаров полностью меняется несколько раз в год;
  
• заказов относительно немного, 200-400 тысяч в год;
  
• история нужна для личного кабинета и набор полей там довольно ограничен.
  

Исходя из этого, выбрали именно JSON, в который складывались все связанные модели ("магазин", "товар" и т.п.) в сериализованном виде. В таком виде они хранятся год-два на всякий случай, потом старые записи переносятся в архивную таблицу, где только реально используемые на странице истории поля со скалярными типами (путь к картинке, название "магазина" и т.п.).

Но тут надо бы реальную задачу понимать. Может, не надо джойнить, а проще денормализовать данные и вести отдельные таблицы какой-то статистики? Или просто отдельно хранить те поля, по которым предполагается джойнить, а всё остальное пихать в JSON?
В отрыве от конкретных задач вариант широкой "дырявой" таблицы мне кажется самым плохим, вариант с таблицей покупки, к которой полиморфично (properties_type, properties_id) привязаны таблицы со значениями свойств каждого типа сущности выглядит немного лучше.

GIF использует lzw-сжатие без потерь. Уменьшить размер файла можно только убрав часть информации, то есть уменьшив разрешение изображения или количество цветов.