ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] mysql



Ilya Obshadko wrote:
> 
> >>    Это известная засада. На простых запросах MySQL весьма быстр, но стоит
> >> начать запрос усложнать - скорость резко падает...
> SS> А чего, explain у mySQL совсем бесполезен?
> 
> О птичках. Натолкнулся на потрясающий эффект. Берем 2 запроса:
> 
> select a.*, b.* from a left join b on a.id = b.id
> 
> select a.*, b.* from a, b where a.id = b.id
> 
> В первом варианте первичный ключ таблицы a НЕ ИСПОЛЬЗУЕТСЯ,
Ключевой индекс, видимо?

> что очевидным образом приводит к full table scan...
Честно говоря, тут не очевидно, что он мог бы дать какой-то эффект -
ведь никаких условий на a.id не наложено, кроме a.id = b.id, но его по
этому индексу все равно проверить нельзя - там ведь b.id нету. Да и a.*
у тебя в индексе вряд ли валяется. А индекс придется просканировать все
равно весь.

В общем вполне возможно что судьба такой, и в этом случае full scan
может быть эффективнее - все равно данные где-то доставать надо. Вот
если бы было что-то типа a.id in(тра-ля-ля) and a.id = b.id, то для
отбора по первому условию можно было бы задействовать индекс.
=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.