Cоставлен следующий запрос:

// fixed 
    $ql = "SELECT u.*, UNIX_TIMESTAMP(u.regdate) AS regdate, c.domain_active, c.approved FROM ".TBL_USER." as u LEFT JOIN ".TBL_COMPANY_NEW." as c ON u.id=c.id_user";
    $ql .= " WHERE u.site_active='1' AND u.v_255_8!='' AND c.domain_active='1' AND c.approved='1'";



В таблице компаний 10 000 записей, в талице пользователей 100 000
 
Не будет ли данный запрос тяжелым, может все лучше через несколько селектов и массив ?

А кто его знает...

Возможно целесообразно создать составные индексы?
А перед соединением выполнять фильтрацию по WHERE.

Наверное я это имею в виду.


Не понял.

Запрос к таблице компаний и в массив.
Запрос к таблице пользователей - в массив, а далее объединить эти массивы.

Ну судя по всему мы говорим об одном и том же (только я бы сказал не массив, а поздапрос, но не суть важно).
Да, так можно сделать, но эффективность нужно проверить на практике.

И стоти оценить целесообразность применения индексов.
Как часто таблциа обновляется, как часто читается, по каким полям при чтении производится выборка, селективность этих полей и т.п.
Мне в свое время составные индексы очень сильно увеличили быстродействие (один-два порядка).

Либо оставить, как есть до появления проблем?

Я тут не советчик, т.к. практического опыта у меня нет.
Вобщем, конечно же, если работает, то за зря мучаться не стоит.

Кроме того у меня буквально месяц назад произошел удивительный конфуз, при попытке соптимизировать запрос именно таким способом о котором мы сейчас говорим, я не получил выигрыша (СУБД: Firebird 2.1). Я уже не вспомню, сколько там записей было и что к чему, но тем не менее, осадок остался... Поэтому я и рекомндую обязательно проверить это на практике, а там видно будет.

Не похоже на то, что селективность u.site_active='1' может быть высокой. Критерий u.v_255_8!='' тоже на вскидку не выглядит селективным, к тому еще индекс для поиска по неравенству использоваться не сможет.  То же самое и по компаниям, из нанзваний полей логичнее предположить что у предикатов скорее низкая селективность нежели высокая. Фулскан и хэш джойн на вскидку выглядят оптимальным планом для этого запроса, а этот план не требует индексов.

Если же мои оценки селективности ложны... тогда другое дело, быть может и можно что-то и можно будет замастырить. 

Это сообщение отредактировал(а) Zloxa - 6.7.2012, 12:37

Спасибо всем! Буду наблюдать и тестировать.

Мне кажется такое решение, при грамотной реализации, вполне может оказаться производительнее.
Но.
1)Стоимость(время) реализации такого подхда существенно выше использования SQL.
2)Пока обе ваши выборки помещаются в память, вы на коне, если изначально допускать возможность, что в память вы не поместитесь, стоимость(время) реализации существенно увеличивается.

Мне лично кажется, что профит от самостоятельной реализации объединения, в очень, очень редком случае способен покрыть затраты на  эту самую реализацию.