[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Оптимизация SQL запроса.
Семён
Сижу целый день не могу добиться высокой скорости запроса:

SELECT
DISTINCT
`db_pars`.`idx_name`
FROM `db_items`
LEFT JOIN `db_pars` USING (`idx`)
WHERE
`db_items`.`user_id` = 0
AND `db_items`.`mod` = 1,
AND `db_items`.`enabled` = 1,
GROUP BY `db_items`.`idx`
ORDER BY `db_pars`.`idx_name`


Суть следующая, есть таблица db_items из которой нужно выбрать определённые значения согласено условию WHERE, а также определить их имя, которое лежит в таблице db_pars, в обоих таблицах есть колонка idx по которому и происходит JOIN.

~ в таблице db_items 400K записей
в таблице db_items 1 составной индекс (mod,user_id,enabled,idx) (именно в таком порядке)

~ в таблице db_pars 90K записей
в таблице db_pars 1 индекс на idx (уникальный)

Скорость выполнения запроса: 0,23c (на буке)
Результатом я крайне недоволен, хотелось бы услышать ваше мнение.

Ах да чуть не забыл прилагаю explain:
1	SIMPLE	db_items	ref	item_index	items	6	const,const,const	58959	Using where; Using index; Using temporary; Using filesort
1 SIMPLE db_pars eq_ref idx_index idx 4 devel.db_items.idx 1




Спустя 21 минута, 1 секунда (15.09.2011 - 18:35) caballero написал(а):
ссделай отдельныйе индексы в обоих таблицах на поле по которому join
на фига там вообще составной индекс да еще и по 4 полям

Спустя 1 час, 9 минут, 26 секунд (15.09.2011 - 19:44) Семён написал(а):
caballero
Составной, упорядочный индекс работает быстрее.
Мои слова может подтвердить разработчик MySQL smile.gif

Цитирую:
rgbeast
Цитата
DISTINCT, согласно описанию, выполняет неявный GROUP BY.
Отличие в производительности может быть, но объяснить его рационально сложно.
Индексы использует, но нужны правильные составные индексы,
так как GROUP BY выполняется после WHERE.

Спустя 6 часов, 13 минут, 59 секунд (16.09.2011 - 01:58) Семён написал(а):
Прогулялся и идея сама пришла в голову.
Пока переделал до такого:
SELECT idx_name FROM (
SELECT b.idx_name
FROM db_items as c
INNER JOIN db_pars as b USING(idx)
WHERE
c.user_id=0
AND c.mod=2
AND c.enabled=1
GROUP BY c.idx
) as idx_name
GROUP BY MD5(idx_name)

Скорость выполнения запроса 0,11
Если сократить время ещё в 2 раза , то я буду феерически счастлив.

Спустя 1 час, 47 минут, 40 секунд (16.09.2011 - 03:46) kirik написал(а):
Семён
Даёшь дамп! smile.gif

Цитата (Семён @ 15.09.2011 - 12:44)
Составной, упорядочный индекс работает быстрее.

Быстрее, но не в твоём случае. В первой таблице idx стоит последний, а в составных индексах индексы по полям используются только в случае, если известны все предыдущие.

Спустя 4 минуты, 38 секунд (16.09.2011 - 03:51) Семён написал(а):
kirik
Что предлагаешь? )))
Пробовал по отдельности, медленнее
Потеря ~0,4 сек. происходит при группировке idx_name, а не idx smile.gif
Цитата
Даёшь дамп! smile.gif

Хитрый какой))) Юзеры будут невольны)))

Спустя 4 часа, 4 минуты, 42 секунды (16.09.2011 - 07:55) kirik написал(а):
Семён
Какие значения могут принимать поля mod, user_id и enabled?
И каков EXPLAIN твоего запроса с вложенным селектом?

Спустя 5 часов, 33 минуты, 25 секунд (16.09.2011 - 13:29) Семён написал(а):
Переделал таблицу pars в InnoDB + сделал отдельный индекс на idx_name тамже, скорость работы -0.02, текущий результат 0,09, но это не предел!!!

Спустя 2 часа, 13 минут, 50 секунд (16.09.2011 - 15:43) Семён написал(а):
Оптимизировать запрос быстрее 0.08 не смог, я доволен результатом )

Спустя 56 минут, 15 секунд (16.09.2011 - 16:39) vital написал(а):
Цитата (Семён @ 16.09.2011 - 12:43)
Оптимизировать запрос быстрее 0.08 не смог, я доволен результатом )

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

Спустя 4 часа, 36 минут, 21 секунда (16.09.2011 - 21:15) kirik написал(а):
Семён
Крут! 0.08 это с SQL_NO_CACHE?

Спустя 1 день, 2 часа, 39 минут, 36 секунд (17.09.2011 - 23:55) Семён написал(а):
kirik
Угу xD
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.