Yuri Morozov

Сколько безысходности в одном коротком посте...

В какой-то момент начал сжираться перевод строки, полагаю.
Krugozor вообще фиг знает что такое, используйте PDO, не выеживайтесь.

Возможно, я не понял задачи, но что мешает сделать это в один запрос?
select ..., SUM(кол-во товара)
where ...
group by [ид_компании,] дата
order by дата desc
limit 7?

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

А дальше варианты: можно сделать отдельные прослойки под API и под веб, в простых случаях можно и одной обойтись (что-то типа if (хочет json) { вернуть json; } else {вернуть html} )

Что нужно знать:

1. при группировке следует указывать либо аггрегирующую функцию, либо прописывать поле в условиях, либо не выбирать поле вообще, иначе результат будет неопределен (MySQL такое прощает, но вообще говоря нельзя так).
К примеру: SELECT MAX(creation_datetime) ... GROUP BY user_id, receiver_id

2. По агрегатам можно не только сортировать, но и накладывать на них условия.
К примеру:
SELECT MAX(creation_datetime) AS m ... GROUP BY user_id, receiver_id ORDER BY m desc HAVING m > ...

3. Вы задолбаетесь каждый раз писать creation_datetime, от этого болят руки и развивается воспаление карпального канала. Общепринятыми названиями подобных полей являются created_at, updated_at, deleted_at, ...

4. ENUM(0, 1) - это пять :)

При нарушении ПДД непременно должен предлагаться in-app purchase для решения проблемы на месте.

У Вас в таблице atributes у записей с id 4426 и 394 одинаковые артикулы (708089), отсюда и дублирование.

По идее, так быть не должно, исправьте, поставьте проверку на unique.

Если же это какой-то хитроумный ход - тогда не могу предложить ничего лучше group by id (что, кстати, совершенно неверно с точки зрения sql, правильное решение несколько длинее, но mysql схавает и такое).

В max_connections уткнетесь.

Вам придется либо шпиговать сервер памятью, либо при любом удобном случае закрывать пользовательское соединение с БД.

В гипотетической ситуации, когда max_connections == 100, и сто пользователей открыли соединение и тупят - сто первый пользователь получит отлуп (если только он не суперюзер).

Выборка по PK (или, в Вашем случае, его части) достаточно быстра, но сначала задайтесь вопросом: а нужны ли Вам все лайки юзера? Сомневаюсь, что Вы хотите вывести их на одной странице, ибо юзер может лайкать много и долго.

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