난수 및 조인 유형의 예기치 않은 결과

4 개의 임의의 숫자 (1 ~ 4)를 얻은 다음 일치하는 database_id 번호를 얻기 위해 다시 결합하는 간단한 스크립트가 있습니다. LEFT JOIN으로 스크립트를 실행하면 매번 4 개의 행이 반환됩니다 (예상 결과). 그러나 INNER JOIN으로 실행하면 다양한 수의 행 (때로는 2, 때로는 8)이 나타납니다.

논리적으로, database_ids 1-4의 행이 sys.databases에 있다는 것을 알고 있기 때문에 아무런 차이가 없어야합니다. 그리고 조인이 아닌 4 개의 행이있는 난수 테이블에서 선택하므로 4 개를 초과하는 행이 반환되지 않아야합니다.

이것은 SQL Server 2012와 2014 모두에서 발생합니다. INNER JOIN이 다양한 수의 행을 반환하는 원인은 무엇입니까?

/* Works as expected -- always four rows */

SELECT rando.RandomNumber, d.database_id
FROM 
  (SELECT 1 + ABS(CHECKSUM(NEWID())) % (4) AS RandomNumber 
   FROM sys.databases WHERE database_id <= 4) AS rando
LEFT JOIN sys.databases d ON rando.RandomNumber = d.database_id;


/* Returns a varying number of rows */

SELECT rando.RandomNumber, d.database_id
FROM 
  (SELECT 1 + ABS(CHECKSUM(NEWID())) % (4) AS RandomNumber 
   FROM sys.databases WHERE database_id <= 4) AS rando
INNER JOIN sys.databases d ON rando.RandomNumber = d.database_id;

/* Also returns a varying number of rows */

WITH rando AS (
  SELECT 1 + ABS(CHECKSUM(NEWID())) % (4) AS RandomNumber
  FROM sys.databases WHERE database_id <= 4
)

SELECT r.RandomNumber, d.database_id
FROM rando AS r
INNER JOIN sys.databases d ON r.RandomNumber = d.database_id;

추가 SELECT를 추가하면 계산 스칼라 평가가 계획으로 더 깊이 들어가고 결합 술어를 제공하고 맨 위에있는 계산 스칼라가 이전 계산 스칼라를 참조합니다.

SELECT rando.RandomNumber, d.database_id
FROM 
  (SELECT ( SELECT 1 + ABS(CHECKSUM(NEWID())) % (4)) AS RandomNumber 
   FROM sys.databases WHERE database_id <= 4) AS rando
INNER JOIN sys.databases d ON rando.RandomNumber = d.database_id

|--Compute Scalar(DEFINE:([Expr1071]=[Expr1070]))

|--Compute Scalar(DEFINE:([Expr1070]=(1)+abs(checksum(newid()))%(4)))

여전히 늦게 기다리는 이유에 대해 파고 있지만 현재 Paul White 가이 게시물을 읽습니다 ( https://sql.kiwi/2012/09/compute-scalars-expressions-and-execution-plan-performance.html ) . 아마도 NEWID가 결정적이지 않다는 사실과 관련이 있습니까?

이것은 사이트의 더 똑똑한 사람들 중 하나가 울릴 때까지 약간의 통찰력을 줄 수 있습니다.

임의의 결과를 임시 테이블에 넣고 조인 유형에 관계없이 일관되게 4 개의 결과를 얻습니다.

/* Works as expected -- always four rows */

DECLARE @Rando table
(
    RandomNumber int
);

INSERT INTO
    @Rando
(
    RandomNumber
)
-- This generates 4 random numbers from 1 to 4, endpoints inclusive
SELECT
    1 + ABS(CHECKSUM(NEWID())) % (4) AS RandomNumber
FROM
    sys.databases
WHERE
    database_id <= 4;

SELECT
    *
FROM
    @Rando AS R;

SELECT
    rando.RandomNumber
,   d.database_id
FROM 
    @Rando AS rando
    LEFT JOIN 
        sys.databases d 
        ON rando.RandomNumber = d.database_id
ORDER BY 1,2;


/* Returns a varying number of rows */

SELECT rando.RandomNumber, d.database_id
FROM 
    @Rando AS rando
    INNER JOIN 
        sys.databases d 
        ON rando.RandomNumber = d.database_id
ORDER BY 1,2;

/* Also returns a varying number of rows */

WITH rando AS 
(
    SELECT * FROM @Rando AS rando
)
SELECT r.RandomNumber, d.database_id
FROM 
    rando AS r
    INNER JOIN 
        sys.databases d 
        ON r.RandomNumber = d.database_id
ORDER BY 1,2;

두 번째 쿼리와 변형 간의 쿼리 계획을 테이블 변수와 비교하면 둘 사이에 명확한 차이가 있음을 알 수 있습니다. 빨간색 X는 No Join Predicate원시인 개발자의 두뇌에 정말 이상하게 보입니다.

임의의 쿼리 비트를 상수 1 % (4)로 제거하면 계획이 더 좋아 보이지만 Compute Scalar가 제거되어 더 가깝게 보입니다.

조인 후 난수에 대한 표현식을 계산합니다. 그것이 예상 되더라도, 나는 여전히 사이트의 내부 마법사로 떠나지 만 적어도 당신이 참여할 때 다양한 결과를 얻는 이유입니다.

2014 년

집에서 놀고있는 사람들을 위해 위의 쿼리 계획은 2008 R2 인스턴스에서 생성되었습니다. 2014 년 계획은 다르게 보이지만 Compute Scalar 작업은 가입 후에도 유지됩니다.

상수 표현식을 사용한 2014 년의 쿼리 계획입니다.

이것은 newid 표현식을 사용하는 2014 인스턴스에 대한 쿼리 계획입니다.

이것은 분명히 의도적으로 설계된 것입니다, 연결이 발행 여기. 그 사실을 알고있는 @paulWhite에게 감사드립니다.