Имеется таблица:
id    idf    idc    idg    price
int(11) AUTO_INCREMENT    int(11)    int(11)    int(11)    int(11)

Ориентировочное количество записей в таблице – несколько миллионов записей <10млн.
Смысл данных содержащихся в каждом столбце:
id – стандартный автоинкремент
idf – идентификатор магазина
idc – идентификатор товара
idg – идентификатор города
price – цена на товар соответствующий идентификатору товара idc (руб)
Пользователь помещает в корзину несколько товаров, каждому товару соответствует свой idc. Для каждого товара пользователь задает количество – целое число >=1.
Пользователь интересуется магазинами в определенном городе (idg).
Необходимо вычислить те магазины, в которых имеются все перечисленные товары. (Информация об остатках в конкретном магазине неизвестна и не должна учитываться – считается, что если товар в таблице есть, то товаров данной номенклатуры неограниченное количество в данном магазине).
В расчете необходимо вычислить суммарную стоимость всех товаров с учетом заданного пользователем количества каждого товара.

Реализовал задачу для  случая при котором количества каждого товара равно 1:
Предположим, что пользователь положил в корзину два товара с idc: 90 и 695.
SELECT SQL_CALC_FOUND_ROWS idf,SUM(price) FROM table WHERE idg='12312' AND idc IN (90,695) GROUP BY idf HAVING COUNT(DISTINCT idc)=2 ORDER BY SUM(price) LIMIT 0,10
А вот как решить задачу в общем случае не знаю. А именно когда для каждого товара пользователь может произвольно задать любое требуемое количество.
Предполагаю, что для решения задачи необходимо создать хранимую процедуру и поместить ее в запрос вместо SUM, которая бы вычисляла сумму с учетом количества товаров.
Могу также предположить, что данной пользовательской функции необходимо будет передавать некоторый параметр, который бы содержал внутри себя указание о том – какой товар в каком количестве требуется подсчитывать.
Например: SUM2(‘695|1|90|5’)
695 – 1 шт
90 – 5 шт

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

А за каким хреном там SQL_CALC_FOUND_ROWS?


Да вот именно так и решить. Идеологически, в смысле. Ну а поскольку количество заранее неизвестно - разумно формировать текст запроса динамически. На клиенте или на сервере - это уже второй вопрос.


Лучше temporary table.


В MySQL нет такого понятия как "виртуальная таблица".


Да. Но его оптимальность вызывает большие сомнения.

Akina,  в запросе указано ограничение LIMIT 0,10, а это значит я получаю только первые 10 записей удовлетворяющих условию. А для того чтобы узнать их общее количество как раз и делается  SQL_CALC_FOUND_ROWS.