левое соединение - бесконечный цикл (никогда не возвращается)

У меня есть таблица и одно сложное представление со следующими подсчетами строк

таблица cpi - количество строк = 74559 представление most_recent - количество строк = 69832

затем я попытался сделать следующий запрос

SELECT DISTINCT TOP 201 cpi.cbuno,  cpi.casebook, v.status_uno
 FROM CPI cpi 
 inner JOIN most_recent v ON v.cbuno=cpi.cbuno
 where isnull(v.status_uno, -1) = 669

и я получил результаты быстро. затем я попробовал это с левым соединением следующим образом

SELECT DISTINCT TOP 201 cpi.cbuno,  cpi.casebook, v.status_uno
 FROM CPI cpi 
 left JOIN most_recent v ON v.cbuno=cpi.cbuno
 where isnull(v.status_uno, -1) = 669

затем он проходит через бесконечный цикл... никогда не возвращает значение. и еще одна вещь, которую следует упомянуть, если я использую v.status_uno = 669 вместо (v.status_uno, -1) = 669 в предложении where, он проходит через тот же бесконечный цикл. Вы, ребята, имеете какое-нибудь представление об этом?

Ценю вашу помощь

спасибо, кет


sql-server-2008 left-join isnull
person keth    schedule 06.05.2013    source источник
comment
привет Олаф, да, это опечатка, извините за это .. я только что исправил, спасибо   -  person keth    schedule 06.05.2013
comment
сколько нулей у вас есть в most_recent.cbuno и most_recent.status_uno?   -  person Alex Turbin    schedule 06.05.2013
comment
в most_recent.cbuno нет нулей, но есть 25 строк с нулями для most_recent.status_uno   -  person keth    schedule 06.05.2013
comment
Сколько строк в недавнем? Это больше вопрос производительности. Я не верю, что вы можете получить бесконечный цикл в SQL. Но у вас могут быть крайне неэффективные запросы   -  person Justin Pihony    schedule 06.05.2013

Ответы (1)


arrow_upward
0
arrow_downward

Может быть...

SELECT DISTINCT TOP 201 cpi.cbuno,  cpi.casebook, v.status_uno
 FROM CPI cpi 
 LEFT JOIN most_recent v 
   ON v.cbuno=cpi.cbuno 
     and v.status_uno=669
person xQbert    schedule 06.05.2013
comment
Привет, xQbert, спасибо за ответ. Да, я пробовал это, но не повезло - person keth; 06.05.2013
comment
в обеих таблицах есть столбец с именем cbuno, и в обеих таблицах этот столбец проиндексирован или настроен как отношение первичного/внешнего ключа, верно? на этом этапе нам нужно будет увидеть результаты анализа запроса (какие индексы он использует, выполняет ли он сканирование таблицы и где и т. д.). - person xQbert; 06.05.2013
comment
Most_recent — это представление, а не таблица, а CPI.cpi — это первичный ключ для таблицы CPI, и он имеет индекс pk. - person keth; 06.05.2013
comment
Вид, вероятно, проблема. Если это не индексированное представление, вы не можете поместить в него индекс, и оно не будет использовать индексы. Таким образом, левое соединение должно выполнять полное сканирование таблицы для каждой записи в таблице. Таким образом, приходится соединять каждую строку 69832 раза. все без индекса. Попробуйте вместо этого создать индексированное представление. просто посмотреть и посмотреть производительность парить. из-за того, что не нужно генерировать декартово значение из более чем 5 миллиардов записей. или ссылка msft - person xQbert; 06.05.2013