[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Оптимизация запроса
Страницы: 1, 2, 3
gzim9x
olya-kowka
надеюсь, у вас в запросе не как в EXPLAIN count(idw) при существующем поле id...
короткий рецепт: создайте 3 индекса: на go, price и stoun
и с вашим количеством записей по поводу циклов можно не волноваться...

STOP -- а они у вас уже есть!!!

_____________
Блокнот дает понимание, Eclipse/Zend studio - скорость, Emacs - свободу.
olya-kowka
Цитата (gzim9x @ 21.06.2010 - 12:21)
olya-kowka
надеюсь, у вас в запросе не как в EXPLAIN count(idw) при существующем поле id...
короткий рецепт: создайте 3 индекса: на go, price и stoun
и с вашим количеством записей по поводу циклов можно не волноваться...

Спасибо за совет. Только я не совсем поняла, о чем Вы

надеюсь, у вас в запросе не как в EXPLAIN count(idw) при существующем поле id...

Поле id? у меня нет такого поля в таблице, или я Вас не так понимаю?

_____________
Столько дел...Не успеваю на все забить!!
gzim9x
у вас в EXPLAIN count( idw )... a в коде вы написали ... count(item) -- да и вообще запрос другой...

для оптимизации запроса по коду php вам нужно только добавить индекс на price.

_____________
Блокнот дает понимание, Eclipse/Zend studio - скорость, Emacs - свободу.
olya-kowka
Цитата (gzim9x @ 21.06.2010 - 12:31)
у вас в EXPLAIN count( idw )... a в коде вы написали ... count(item) -- да и вообще запрос другой...

для оптимизации запроса по коду php вам нужно только добавить индекс на price.

ну я просто item написала вместо idw. Конечно же, запросы выполняются в том виде, в котором я написала при Explain.

Спасибо за помощь, поставлю индекс на price.

_____________
Столько дел...Не успеваю на все забить!!
gzim9x
olya-kowka
Цитата
ну я просто item написала вместо idw. Конечно же, запросы выполняются в том виде, в котором я написала при Explain.

Спасибо за помощь, поставлю индекс на price.

да в том то и дело что price вам поможет при запросе который вы указали первоначально -- тот что в цикле. Если вы хотите оптимизировать приведенный запрос из Explain -- там этот индекс никак не поможет.
Определитесь что нужно оптимизировать!

_____________
Блокнот дает понимание, Eclipse/Zend studio - скорость, Emacs - свободу.
olya-kowka
gzim9x


Так а почему не поможет оптимизация запроса в explain? Этот именно запрос и будет крутиться у меня в цикле.

_____________
Столько дел...Не успеваю на все забить!!
SlavaFr
@olya-kowka если ты загониш диапозоны в специальную таблицу которая состоит из Id,zena_ot,zena_do,

то ты можеш все решить одним единственным SQL в котором ты зделаеш join с диапозонтаблицей и групировкой group by type, diaposon_id

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();
olya-kowka
SlavaFr

а join по каким полям между двумя таблицами?

_____________
Столько дел...Не успеваю на все забить!!
SlavaFr
inner join price_diaposon on price> price_diaposon.zena_ot and price<price_diaposon.zena_do

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();
gzim9x
olya-kowka
Цитата
Так а почему не поможет оптимизация запроса в explain? Этот именно запрос и будет крутиться у меня в цикле.

EXPLAIN SELECT count( idw ) 
FROM table
WHERE TYPE =1
AND go =1
AND price * disc >0
AND price * disc *27 <1500
AND stoun =1
AND descr LIKE '%брилл%'

потому как много времени уходит именно на вычисление (price * disc) и (price * disc *27) а price здесь является лишь множителем и индекс по price использоваться не будет...
если хотите оставить все в одной таблице -- или внедряйте поле "диапазон" или поля "price_disc", "price _disc_27" с предварительным подсчетом -- делайте по ним индекс и используйте в запросе.


_____________
Блокнот дает понимание, Eclipse/Zend studio - скорость, Emacs - свободу.
tomash
Добавьте поле group_price

SELECT type, group_price, count(type) FROM table GROUP BY type, group_price


т.е. price < 1500 - group_price =1,
1500 < price < 3000 - group_price = 2 ну и т.д.

_____________
Чтобы понять, что такое рекурсия - нужно понять, что такое рекурсия.
Nikitian
price * disc >0 можно и нужно заменить на
....
(
price>0 or disc>0)
...

price * disc *27 <1500
Заменить на

price*disc <55.5

По нужным индексам сориентирую позже. Для этого покажите show create table `table`

Цитата (olya-kowka @ 21.06.2010 - 11:20)

Большая таблица с кучей полей и поэтому никаких join делать не нужно, вся выборка идет только отсюда.


Что мешает джойнить таблицу саму на себя? Или, как вариант, конвертнуть табличку в myisam_merge и тем самым разбить всё на отдельные маленькие быстрые таблички. Кто говорит, что одна таблица быстрее - ударить по голове.
olya-kowka
Nikitian, SlavaFr

Вашими методами удалось огранизовать действительно быструю выборку.

Ребят, спасибо за помощь. Очень помогли!



_____________
Столько дел...Не успеваю на все забить!!
dsa
Здравствуйте я сейчас делаю :D ну ток не смейтесь мини онлайн игу
И вот задался я целью ее хоть как-то оптимизировать вот у меня вопрос имеет ли преимущество в скорости выполнения вот такой запрос
$req = mysql_query("SELECT `vesh`.* FROM `inven`, `veshi` WHERE `inven`.`yzer` = '" . $yzer . "' AND ((`inven`.`odeto` = '" .$ruki . "') or (`inven`.`odeto` = '" . $nogi . "') or (`inven`.`odeto` = '" . $golova . "')) AND `inven`.`refer` = `vesh`.`id`");

перед таким
$query_inv = mysql_query("SELECT * FROM `inven` WHERE `yzer` = '" . $yzer . "'");
while($inventar = mysql_fetch_array($req)){
if($inventar['odeto'] == $ruki || $inventar['odeto'] == $nogi || $inventar['odeto'] == $golova){
$veshi = mysql_fetch_array(mysql_query("SELECT * FROM `vesh` WHERE `id` = '" . $inventar['refer'] . "'"));
echo $veshi['name'];
}
}

И если нет то каким более быстрым запросом его можно заменить?
Просто в таблице inven по идее может быть большое кол-во записей и вопрос оптимизации как мне кажется именно для этого случая очень акуален
inpost
dsa
Со своими вопросами в свои темы...

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Быстрый ответ:

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