Проблемы с оптимизацией запроса MySQL

Проблемы с оптимизацией запроса MySQL

Опции

devuser

Topic Starter сообщение

7.5.2013, 23:07; Ответить: devuser

Сообщение #1

Все будет тип-топ

Группа: Active User
Сообщений: 713
Регистрация: 5.12.2012
Из: Online
Поблагодарили: 343 раза
Репутация:

52

Доброго всем времени суток.

Столкнулся с проблемой, хочу услышать советы коллег.

Итак, имеем интернет-магазин. Часть его БД, с которой мы будем работать, имеет следующую структуру:

Звездочкой отмечены поля Primary Index

Описание БД
Таблица Products – таблица товаров
Таблица ProductsCatNUM – таблица соответствия каталожного номера и товара
Таблица CatNUMs – список каталожных номеров товара
Таблица CatNUMs2Categories – соответствие каталожного номера и категории.
Таблица Category – список категорий сайта

Количество записей в таблицах:
Таблица Products – 25 000
Таблица ProductsCatNUM – 20 000
Таблица CatNUMs – 230 000 (катномера выгружены все, а продукты еще не все, поэтому такая разница)
Таблица CatNUMs2Categories – 1 200 000
Таблица Category – 10 000

Запросы:

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

Запрос на получение списка товаров в конечной ( у которой больше нет дочерних ) категории выглядит так:

SELECT DISTINCT `p`.`id`
    FROM (`products` p)

    JOIN `productsCatNUM ` pc ON `pc`.`productID` = `p`.`id`
    JOIN `CatNUMs2Categories` cn2c ON `cn2c`.`catNumID ` = `pc`.`CatNumID `

    WHERE
        `p`.`actual` =  1 AND `cn2c`.`CategoryID` = 19125

    ORDER BY `p`.`title` asc
    LIMIT 10

Запрос на получение списка товаров в неконечной категории ( для которой еще нужно учитывать все дочерние категории ) выглядит так:

SELECT DISTINCT `p`.`id`
    FROM (`products` p)

    JOIN `productsCatNUM ` pc ON `pc`.`productID` = `p`.`id`
    JOIN `CatNUMs2Categories` cn2c ON `cn2c`.`catNumID ` = `pc`.`CatNumID `

    WHERE
        `p`.`actual` =  1 AND `cn2c`.`CategoryID` IN (19,19001,19002,19005,19007,19012,19016,19020,19024,
                            19028,19032,19035,19147,19038,19039,19053,19062,19065,
                            19071,19072,19077,19085,19148,19090,19091,19094,19102,
                            19149,19104,19105,19115,19124,19125,19134,19142,19144,19145
                            )

    ORDER BY `p`.`title` asc
    LIMIT 10

Проблемы

Запрос в конечной категории выполняется две-три секунды.
Запрос на получение списка товаров в неконечной категории выполняется 10 секунд.

Это, собственно, и недопустимо, требуется оптимизировать.

БД MySQL, таблицы InnoDB

Менять структуру БД не готовы, на ней завязаны другие фишки. Возможно какие-то временные данные генерировать при импорте (какие?)
Рут на сервер, в принципе, есть, но не желательно тюнить БД, хотя и возможно.

Буду благодарен за любые советы.
Спасибо

Сообщение отредактировал devuser - 7.5.2013, 23:11

--------------------

Профессиональные услуги веб-разработчика
Грамотная, профессиональная верстка макетов
Подружим Ваш интернет-магазин с системой 1С

0

Ответить с цитированием данного сообщения

tszyan

8.5.2013, 20:27; Ответить: tszyan

Сообщение #2

Участник

Группа: User
Сообщений: 207
Регистрация: 28.1.2013
Из: Москва
Поблагодарили: 110 раз
Репутация:

27

devuser,
Хм, как насчет того, что генерировать таблицу products_categories:
id(*)
product_id
category_id

Тогда если Вы работаете только с id, как в примерах, то SELECT будет из одной таблицы, по 1 условию. (UPDATE: вру, там у Вас сортировка, значит из 2х таблиц).

Также при достаточном количестве памяти - можно кэшировать результаты запросов или даже перенести в память таблицы со связями.

Я не любитель теоретических выкладок, была бы база - поэкспериментировал бы.
Надо посмотреть план запроса, посмотреть как влияет каждый элемент на него. Хоть запрос и простой, но без данных мне трудно сказать сильно ли повлияет замена 2 таблиц со связями одной, возможно ли размещение части данных в памяти и что это даст. Да даже другой вариант запроса с таким же количеством связей не проверить.

Да и непонятно, действительно ли причина столь долгого выполнения в самом запросе, а не в настройках или доступных ресурсах.

Замечание модератора:
Эта тема была закрыта автоматически ввиду отсутствия активности в ней на протяжении 100+ дней.
Если Вы считаете ее актуальной и хотите оставить сообщение, то воспользуйтесь кнопкой

или обратитесь к любому из модераторов.

Сообщение отредактировал tszyan - 8.5.2013, 20:20

Поблагодарили: (1)

devuser

« Предыдущая тема · Программная часть · Следующая тема »

1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)

Пользователей: 0

Похожие темы

Тема	Ответов	Автор	Просмотров	Последний ответ
Верстка + Разработка веб-приложений на базе: Yii Framework 2, Laravel, MySQL Верстка,правка косяков/багов + другая работа. Доступные цены.	12	Fortunatus	13197	2.3.2021, 9:52 автор: Zementovoz
Проблемы с выплатами РСЯ для Украины	12	metvekot	1467	17.2.2021, 18:02 автор: 0pium
Проблемы с налоговой из за дохода с сайтов	31	TABAK	1659	3.12.2020, 19:46 автор: Webranger
Web программирование на С/С++/PHP/MySQL/SQL, высоконагруженные проекты Есть наработки в области бирж трафика, топов, тизеров, видео cj-тубов	4	DFService	2243	8.4.2020, 18:02 автор: DFService
Копеечная SEO оптимизация и рекламные кампании в Google Ads и Яндекс.Директ., Помощь с SEO оптимизацией и рекламными кампаниями в Google Ads и Яндекс.Директ. Помощь с SEO оптимизацией и рекламными кампаниями в Google Ads и Яндек	3	santeyyy81	1508	9.12.2019, 14:42 автор: santeyyy81