Меню
Что нового?

Разное время выполнения запроса к большой базе

Ekklipce

Новичок
Разное время выполнения запроса к большой базе

запрос

SELECT offer.id AS id, element.name AS name, offer.producer AS producer, element.params AS params, offer.price AS price, supplier.min_offer AS min_offer, supplier.name AS supplier, offer.store_count AS store, offer.period AS period, offer.min_count AS min_package
FROM offer, element, supplier ,cat
WHERE element.id = offer.element
AND supplier.id = offer.supplier
AND element.cat = cat.id
AND cat.sub = '13'
ORDER BY producer, name ASC LIMIT 0, 50

это возможно
1. такой хостинг с таким общением скриптами с базой?
2. неверное построение запроса исходя из поставленной задачи ?
или что то ещё ?
 

Ekklipce

Новичок
собственно про что вопрос ?
все вроде изложил популярно..

этот запрос выпонляется разное время в пределах 10 секунд :)
 

Necromant

Новичок
потому , что их будет еще 2 ... если до конца , запрос допишешь )
 

Ekklipce

Новичок
общий запрос :

SELECT offer.id AS id, element.name AS name, offer.producer AS producer, element.params AS params, offer.price AS price, supplier.min_offer AS min_offer, supplier.name AS supplier, offer.store_count AS store, offer.period AS period, offer.min_count AS min_package
FROM offer
LEFT JOIN element ON element.id = offer.element
LEFT JOIN supplier ON supplier.id = offer.supplier
ORDER BY producer, name ASC

за 32 секунды

общий запрос (другой вариант)

SELECT offer.id AS id, element.name AS name, offer.producer AS producer, element.params AS params, offer.price AS price, supplier.min_offer AS min_offer, supplier.name AS supplier, offer.store_count AS store, offer.period AS period, offer.min_count AS min_package
FROM offer, element, supplier
WHERE element.id = offer.element AND supplier.id = offer.supplier
ORDER BY producer, name ASC
LIMIT 0 , 50

за 11 секунд :)




SELECT offer.id AS id, element.name AS name, offer.producer AS producer, element.params AS params, offer.price AS price, supplier.min_offer AS min_offer, supplier.name AS supplier, offer.store_count AS store, offer.period AS period, offer.min_count AS min_package
FROM offer
LEFT JOIN element ON element.id = offer.element
LEFT JOIN supplier ON supplier.id = offer.supplier
LEFT JOIN cat ON element.cat = cat.id
WHERE cat.sub = '13'
ORDER BY producer, name ASC
LIMIT 0 , 50

за 13 секунд


SELECT offer.id AS id, element.name AS name, offer.producer AS producer, element.params AS params, offer.price AS price, supplier.min_offer AS min_offer, supplier.name AS supplier, offer.store_count AS store, offer.period AS period, offer.min_count AS min_package
FROM offer, element, supplier, cat
WHERE element.id = offer.element AND supplier.id = offer.supplier AND element.cat = cat.id AND cat.sub = '13'
ORDER BY producer, name ASC
LIMIT 0 , 50

за 7 секунд..

причем без LEFT JOIN используются индексы а с ним - наполовину

такие дела

Запросы верно написаны ?
 

Necromant

Новичок
сслыки , почитай выше )) , Mysql не умеет оптимизоолвать, такого вида запросы, зато меет инструменты оптимизации , конструкций вида LEFT JOIN / JOIN
 

chira

Новичок
Ekklipce
что бы ответить на твой вопрос, нужно описание таблиц, количество записей в каждой и explain твоего запроса ...
собственно про что вопрос ?
все вроде изложил популярно..
Нажмите для раскрытия...
ничего не изложил, вместо твоего запроса можно написать любой другой и задать теже вопросы ...
 

Ekklipce

Новичок
сортировка на время никак не влияет..
с ней может дольше на 0.5 с

explain.. верхнего запроса

table-----type----possible_keys--key-----key_len--ref-----------rows---Extra

supplier--ALL-----PRIMARY--------NULL----NULL---- NULL----------4------Using temporary; Using filesort
offer-----index---NULL------------id-------434------NULL----------158456-where used; Using index
element--eq_ref--PRIMARY--------PRIMARY-4--------offer.element--1------where used
cat------eq_ref--PRIMARY--------PRIMARY-4--------element.cat----1------where used

-~{}~ 12.10.05 13:58:

это explain самого первого запроса
 

Necromant

Новичок
у тя индексы не использыются ... !!!! т.е. ИДЕТ . полный перебор всех данных.
 

Ekklipce

Новичок
CREATE TABLE `offer` (
`id` int(10) unsigned NOT NULL auto_increment,
`element` int(11) NOT NULL default '0',
`min_count` varchar(5) NOT NULL default '',
`store_count` varchar(5) NOT NULL default '',
`supplier` int(11) NOT NULL default '0',
`period` varchar(100) NOT NULL default '',
`price` varchar(10) NOT NULL default '',
`name` varchar(150) default NULL,
`producer` varchar(150) default NULL,
`upload` int(11) NOT NULL default '0',
PRIMARY KEY (`id`),
KEY `id` (`id`,`element`,`min_count`,`store_count`,`supplier`,`period`,`price`,`name`,`producer`)
) TYPE=MyISAM AUTO_INCREMENT=716997 ;

создал ключ на поля в запросе...

неужели eq_ref так плох ? тогда какой индекс надо сделать что бы он использовался ?
 

Ekklipce

Новичок
да читал я его... и ничего кардинально нового для себя не нашёл,

а вот интересует что :

- верно ли создал индекс
- как максимально быстро построить запрос с LEFT JOIN

2 Necromant
ответь плизз..теряюсь что то
 

Steamroller

Новичок
Под конкретно этот запрос оптимальные индексы такие:
alter table cat add unique (sub,id);
alter table element add unique (cat,id);
alter table offer add unique (element,supplier); (тут если эта пара по смыслу не уникальна, то index вместо unique, тогда будет ref вместо eq_ref)
alter table supplier drop primary key;
alter table supplier add primary key (id);
либо, если id - неуникальный, то alter table supplier add index (id);
 

Ekklipce

Новичок
CREATE TABLE `element` (
`id` int(10) unsigned NOT NULL auto_increment,
`name` varchar(50) NOT NULL default '',
`producer` varchar(150) NOT NULL default '0',
`cat` int(11) NOT NULL default '0',
`params` varchar(250) NOT NULL default '',
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) TYPE=MyISAM COMMENT='Электронные элементы' AUTO_INCREMENT=149359 ;

там по сути каждая запись уникальна.. есть ли смысл делать уникальный ключ только ли по cat, id, или может сразу на всю запись..

то есть суть метода вижу в присвоении уникальноог ключа уникальным данным в одной таблице
 

Steamroller

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

Ekklipce

Новичок
Даже без LEFT JOIN запрос проходит мгновенно..

однако голый запрос все равно долго думает :

SELECT offer.id AS id, element.name AS name, offer.producer AS producer, element.params AS params, offer.price AS price, supplier.min_offer AS min_offer, supplier.name AS supplier, offer.store_count AS store, offer.period AS period, offer.min_count AS min_package

FROM offer, element, supplier WHERE element.id = offer.element AND supplier.id = offer.supplier ORDER BY producer, name ASC LIMIT 0, 50

EXPLAIN

table-----type----possible_keys-key------key_len---ref------------rows---Extra
element--ALL-----PRIMARY-------NULL----NULL-----NULL----------149358-Using temporary; Using filesort
offer-----ref------element-------element--4--------element.id-----1------where used
supplier--eq_ref---PRIMARY,id----PRIMARY-4--------offer.supplier---1------where used

2 Steamroller
какие здесь будут сходные предложения по ключам и индексам ?...

-~{}~ 12.10.05 15:49:

в element индексы уже существуют, и с ними все просто летает,

PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`),
UNIQUE KEY `element_cat` (`cat`,`id`)

если только не юзать запрос без конкретных условий :(
 
Войдите или зарегистрируйтесь для ответа.
Сверху