| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Составление SQL-запросов > Запрос с join |
| Автор: sergphp 6.7.2012, 08:59 |
| 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 Не будет ли данный запрос тяжелым, может все лучше через несколько селектов и массив ? |
| Автор: Gluttton 6.7.2012, 11:56 | ||||||
А кто его знает... Возможно целесообразно создать составные индексы? А перед соединением выполнять фильтрацию по WHERE.
Наверное я это имею в виду.
Не понял. |
| Автор: sergphp 6.7.2012, 12:06 |
| Запрос к таблице компаний и в массив. Запрос к таблице пользователей - в массив, а далее объединить эти массивы. |
| Автор: Gluttton 6.7.2012, 12:11 |
| Ну судя по всему мы говорим об одном и том же (только я бы сказал не массив, а поздапрос, но не суть важно). Да, так можно сделать, но эффективность нужно проверить на практике. И стоти оценить целесообразность применения индексов. Как часто таблциа обновляется, как часто читается, по каким полям при чтении производится выборка, селективность этих полей и т.п. Мне в свое время составные индексы очень сильно увеличили быстродействие (один-два порядка). |
| Автор: sergphp 6.7.2012, 12:12 |
| Либо оставить, как есть до появления проблем? |
| Автор: Gluttton 6.7.2012, 12:16 |
| Я тут не советчик, т.к. практического опыта у меня нет. Вобщем, конечно же, если работает, то за зря мучаться не стоит. Кроме того у меня буквально месяц назад произошел удивительный конфуз, при попытке соптимизировать запрос именно таким способом о котором мы сейчас говорим, я не получил выигрыша (СУБД: Firebird 2.1). Я уже не вспомню, сколько там записей было и что к чему, но тем не менее, осадок остался... Поэтому я и рекомндую обязательно проверить это на практике, а там видно будет. |
| Автор: Zloxa 6.7.2012, 12:22 | ||
Не похоже на то, что селективность u.site_active='1' может быть высокой. Критерий u.v_255_8!='' тоже на вскидку не выглядит селективным, к тому еще индекс для поиска по неравенству использоваться не сможет. То же самое и по компаниям, из нанзваний полей логичнее предположить что у предикатов скорее низкая селективность нежели высокая. Фулскан и хэш джойн на вскидку выглядят оптимальным планом для этого запроса, а этот план не требует индексов. Если же мои оценки селективности ложны... тогда другое дело, быть может и можно что-то и можно будет замастырить. |
| Автор: sergphp 6.7.2012, 12:54 |
| Спасибо всем! Буду наблюдать и тестировать. |
| Автор: Zloxa 6.7.2012, 13:24 | ||
Мне кажется такое решение, при грамотной реализации, вполне может оказаться производительнее. Но. 1)Стоимость(время) реализации такого подхда существенно выше использования SQL. 2)Пока обе ваши выборки помещаются в память, вы на коне, если изначально допускать возможность, что в память вы не поместитесь, стоимость(время) реализации существенно увеличивается. Мне лично кажется, что профит от самостоятельной реализации объединения, в очень, очень редком случае способен покрыть затраты на эту самую реализацию. |
