SQL Server: почему вы бы бросили на левой стороне оператора? - PullRequest
0 голосов
/ 15 декабря 2011

Я использую SQL Server 2005.

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

JOIN t on cast(a.foo as int) = b.foo

Он сказал мне никогда не делать этого, так как я теряю все преимущества индексации в производительности.

Зачем вам это намеренно делать?

Ответы [ 2 ]

5 голосов
/ 15 декабря 2011

Ну ... Ответ вроде того, что сказал твой друг. Если вы разыгрываете его, он не сможет использовать индексы преимуществ на a.foo. Однако, если вы разыграете правую сторону, вы не сможете воспользоваться индексами на b.foo.

В конце концов, если вы присоединяетесь к несовпадающим типам данных, вам придется где-то потерять. Должно ли оно быть слева или справа от объединения, полностью зависит от плотности данных и от того, какие индексы на самом деле используются для задействованных таблиц (например, это действительно не стоит больших затрат, если a.foo не проиндексирован в любом случае). ).

0 голосов
/ 15 декабря 2011

При написании временного предиката, например

@test_date попадает в закрытый период, ограниченный T.start_date и T.end_date

У меня есть сильное предпочтение расположить меньшую дату на левой стороне, как это было бы на временной шкале, т.е.

WHERE T.start_date <= @test_date
      AND @test_date < T.end_date

Если бы @test_date включал CAST, я бы написал так же изначально. Честно говоря, я бы, вероятно, попытался бы изменить его, если бы возникла проблема с производительностью, потому что логически обоснованный, читаемый код предпочтителен преждевременной оптимизации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...