 |
|
Модераторы: LSD |
 
|
|
замена left join? замена left join на условие в where 
| Akina |
|
|||
|
Советчик  Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
А что вообще делают условая отбора в выражении связывания? -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
Загрузка ...
| skyboy |
|
|||
|
неОпытный Профиль Группа: Модератор Сообщений: 9820 Регистрация: 18.5.2006 Где: Днепропетровск Репутация: 5 Всего: 260 |
подозрительно, правда? возможно, именно из-за этого тормозит. правда, в WHERE не кинешь - это же LEFT JOIN, потому если перебросить условия в WHERE, то потеряем часть строк, для которых t2.RefValue <> 0 или t2.AttrID <> '' |
|||
|
||||
| Deniz |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
Может оптимизатор не умеет/не хочет использовать индекс по с1 и с2 при наличии дополнительного условия связывания? -------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
да я вообще не понимаю этой фигни в условиях отбора... как оно работать-то будет? с одной стороны left join - значит, все записи из t2 должны войти в результирующий набор независимо ни от чего... с другой - какие-то условия связывания... это что, в результате не будет выполняться связывание с записями, что не отвечают условиям, но в результирующий набор они все одно войдут? с null-ами в t1.*? по-моему, лучше построить 2 отдельных запроса и слить их результаты... -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| yezh |
|
||||||
 Шустрый Профиль Группа: Участник Сообщений: 95 Регистрация: 18.12.2005 Где: Москва Репутация: нет Всего: нет |
А как я уберу константые выражения???? У меня рез-т запроса будет совершенно иной! 2 запроса нельзя сделать по разным причинам. Одна из них - нарушится маппинг рез-тов запроса на класс, чего делать нельзя. А вот если бы можно было сделать два запроса и слить их при помощи sql (не программными методами), это ьыло ьы замечательно... Вообще говоря я уже убрал left join, при помощи union'a, однако... запрос работает еще медленнее :( Добавлено через 8 минут и 34 секунды
Народ, а может я не понимаю как работает left join? Мое такое мнение: выбираются все строки из таблицы t1, удовлетворяющие условию в where, затем к рез-ту пристыковываются строки из t2, которые соответствуют условиям в блоке ON Это сообщение отредактировал(а) yezh - 30.11.2007, 15:18 |
||||||
|
|||||||
| skyboy |
|
||||||
|
неОпытный Профиль Группа: Модератор Сообщений: 9820 Регистрация: 18.5.2006 Где: Днепропетровск Репутация: 5 Всего: 260 |
нет. left-join'ится t2, значит, null'ы будут в t2.* Добавлено через 1 минуту и 34 секунды
именно так. если соотвествующих строк в t2 не окажется, то будут "присоединены" NULL'ы. Впрочем, такой запрос подозрительно выглядит. может, можно переджелать структуру БД, чтоб избежать таких запросов? можно получить информацию по логике запроса? что он вообще моделирует? Добавлено через 2 минуты и 56 секунд
меня интересует, в первую очередь, найти действительно узкое место запроса. я не предлагаю тебе просто эти условия удалить, я предлагаю провести эксперимент. который, при отсутствии средств профилирования(говоришь, у тебя 8-я версия, и там нужных инструментов нет?) позволит определить - что же так сильно тормозит. |
||||||
|
|||||||
| yezh |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 95 Регистрация: 18.12.2005 Где: Москва Репутация: нет Всего: нет |
Узкое место? Join. Если просто перенести все условия в where (невзирая на то, что рез-т неполным получится), то работать такой запрос будет порядка 4-х секунд. Если с join - порядка минуты.
Переделать структуру базы я не могу - база от чужого приложения. Т.е. заполняется она именно этим приложением, я лишь беру от туда данные. Запрос же просто получает действия клиента за поределенный промежуток времени. А таких действий оч много (много клиентов), отсюда огромный размер базы Добавлено через 1 минуту и 41 секунду Убирание константных условий не помогло, время выполнения то же. |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Погоди... ты сказал раньше, что у тебя один составной ключ (что очевидно, двух ключей не бывает) - а связываешь по отдельным полям. Гарантированно одно из двух условий связывания не использует ключа. Попробуй связывать строго по тому выражению, которое используется при построении этого первичного ключа.
-------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| yezh |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 95 Регистрация: 18.12.2005 Где: Москва Репутация: нет Всего: нет |
Ммм.. первазив ето такая база в которой может быть скок угодно ключей .. хоть сто
Если при связывании использовать это выражение, то у меня будут дублироваться записи Ключ на самом деле не совсем первичный, в том смысле что он не уникальный. Однако поиск по нему должен выполняться в первую очередь |
|||
|
||||
| skyboy |
|
||||
|
неОпытный Профиль Группа: Модератор Сообщений: 9820 Регистрация: 18.5.2006 Где: Днепропетровск Репутация: 5 Всего: 260 |
оффтоп: помедитировав, пришел к выводу, что Akina под "ключом" понимает "первичный ключ", а ты - любой индекс. просто несоотвествие "внутренних" терминологий 
походу, ключ при связывании не используется. странно :( А если перейти к inner join - скорость возрастет? |
||||
|
|||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
skyboy, ты медитируешь лучше... -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| skyboy |
|
||||||
|
неОпытный Профиль Группа: Модератор Сообщений: 9820 Регистрация: 18.5.2006 Где: Днепропетровск Репутация: 5 Всего: 260 |
не знаю, как в Pervasive, а вот MSSQL и MySQL(с чем работал; по идее, все остальные внеяемые СУБД - тоже) если идет условие(в WHERE или JOIN) на все, включенные в составной индекс поля, применяет обработку этого составного индекса. Не думаю, что Pervasive настолько идиотична, чтоб это игнорировать. А иначе - смысл в составном индексе, если его негде использовать? Вот только мысль есть: а порядок полей в условии такой же, как порядок объявленного следования в индексе(ключе)? Я с Pervasive не работал, но оптимизатор его подозреваю во всех тяжких. -- оффтоп: ещё тут попутно вопрос:
я правильно понял: ты условия связывания в INNER JOIN переместил в секцию WHERE и заработало быстрее? или ты просто объявил INNER JOIN без условия связывания? --
Что-что? |
||||||
|
|||||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Да? как я понял из документации, индекс используется только при обработке выражений с теми полями и их частями, которые стоят в начале выражения для построения индекса... -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| skyboy |
|
|||
|
неОпытный Профиль Группа: Модератор Сообщений: 9820 Регистрация: 18.5.2006 Где: Днепропетровск Репутация: 5 Всего: 260 |
немного перекрученно изложил. индекс может(зависит от оптимизатора) использоваться при обработке выражений, в которые входят все поля, включенные в индекс, либо только те поля, которые стоят первыми при организации индекса. чтоб остальных не запутывать, приведу аналогию: если есть список телефонов, где идет разбивка по городам, затем - по улицам, затем - по номерам домов, то найти телефон, имея все данные - просто, имея названия города и улицы - тоже проще, чем перебирать все. но если из всех данных есть только название города и номер дома(улица не указана), то потенциально быстрее просмотреть таблицу без использования индекса. не понял только, для чего ты это привел. считаешь, что индекс в запросе yezhа использоваться не может? Добавлено @ 18:36 yezh, а можно сервер будет обновить? Это сообщение отредактировал(а) skyboy - 30.11.2007, 18:34 |
|||
|
||||
| yezh |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 95 Регистрация: 18.12.2005 Где: Москва Репутация: нет Всего: нет |
Ок, товарищи, проблема решена. Оказывается, в запросе участвовала не таблица, а структура наложенная на таблицу. Некие же умные программисты в структуру индексов вообще не внесли.
После внесения индексов время работы запросы резко уменьшилось  Убыв бы таких Всем огромное спасибо З.Ы. Кстати, иногда (не знаю почему), бывает такое, что несмотря на все индексы запросы в первазиве работают оч долго (чаще всего при использовании INNER JOIN). Был один такой случай, долго мучались, решили проблему только уберанием этой конструкции. Это вдруг если кто то захочет использовать Pervasive SQL v8.7  |
|||
|
||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0979 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |