форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы WEB технологии (Public)
Изначальное сообщение		[Проследить за развитием треда]

"ресурсоемкий запрос"
Сообщение от MaRk on 02-Окт-03, 14:40  (MSK)
Есть две таблицы: в одной хранятся описания товаров, в другой предметный указатель... CREATE TABLE catalog( catalogid INT(4) UNSIGNED PRIMARY KEY AUTO_INCREMENT, description CHAR(255), measurement CHAR(16), price CHAR(16), company CHAR(64), phone CHAR(32), INDEX (description(16)) ); CREATE TABLE word( wordid INT(4) UNSIGNED PRIMARY KEY AUTO_INCREMENT, word CHAR(64), INDEX (word(16)) ); например в первой таблице может в поле "description" может храниться "Аксессуары для жидких обоев", а во второй в поле "word" - слово "аксессуар". в первой тиблице строк порядка 3-4 тысяч, во второй 1600 строк... запрос типа: SELECT a.catalogid, a.description, a.measurement, a.price, a.company, a.phone, IFNULL(b.word, '') AS keyword FROM catalog.work AS a LEFT JOIN catalog.word AS b ON (a.description LIKE CONCAT(b.word, '%')) GROUP BY a.catalogid ORDER BY a.description выполняется порядка 30 сек. что очень долго. Знаю что join очень ресурсоемкая операция... как можно было бы оптимизировать этот запрос???
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "ресурсоемкий запрос"
Сообщение от konst on 03-Окт-03, 18:24  (MSK)
>Есть две таблицы: в одной хранятся описания товаров, в другой предметный указатель... > >CREATE TABLE catalog( >catalogid INT(4) UNSIGNED PRIMARY KEY AUTO_INCREMENT, >description CHAR(255), >measurement CHAR(16), >price CHAR(16), >company CHAR(64), >phone CHAR(32), >INDEX (description(16)) >); >CREATE TABLE word( >wordid INT(4) UNSIGNED PRIMARY KEY AUTO_INCREMENT, >word CHAR(64), >INDEX (word(16)) >); >например в первой таблице может в поле "description" может храниться "Аксессуары для >жидких обоев", а во второй в поле "word" - слово "аксессуар". > >в первой тиблице строк порядка 3-4 тысяч, во второй 1600 строк... >запрос типа: >SELECT a.catalogid, a.description, a.measurement, a.price, a.company, a.phone, IFNULL(b.word, '') AS keyword >FROM catalog.work AS a LEFT JOIN catalog.word AS b ON (a.description LIKE >CONCAT(b.word, '%')) >GROUP BY a.catalogid >ORDER BY a.description >выполняется порядка 30 сек. что очень долго. Знаю что join очень ресурсоемкая >операция... как можно было бы оптимизировать этот запрос??? imho есурсоемкость здесь в LIKE. Им лучше не пользоваться для типовых запросов. Я бы написал доп.скриптик который сделает эту работу (сравнит наличие слов из табл. word с полем descr и результат загонит в смежную табл. test (word_id int4,catalog_id int4). И стоить потом запросы без LIKE. Если часты обновления - соответствующий скриптик запускающий reindex для табл. test
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "ресурсоемкий запрос"
	Сообщение от MaRk on 03-Окт-03, 20:21  (MSK)
	спасибо, но дело все в том, что это как раз и делалось для обработки неких первоначальных данных, чтоб потом все было быстро, данные поступают каждую неделю, хотелось бы оптимизировать этот запрос, может как то можно от join избавиться, если есть идеи помогите плиз!!
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.