UDF가 전체 직렬 계획을 강제한다는 것은 상당히 잘 문서화되어 있습니다.
잘 문서화 된 것이 확실하지 않습니다.
- 스칼라 T-SQL 함수는 계획의 어느 곳에서나 병렬 처리를 방지합니다.
- 스칼라 CLR 함수는 데이터베이스에 액세스하지 않는 한 병렬로 실행될 수 있습니다.
- 다중 문 테이블 반환 T-SQL 함수는 다른 곳에서 병렬 처리를 사용할 수있는 계획에서 직렬 영역을 강제 실행합니다.
- 인라인 테이블 반환 T-SQL 함수는 뷰처럼 확장되므로 직접적인 영향은 없습니다.
참조 병렬 실행 계획 강제 및 / 또는 크레이그 프리드먼의 병렬 실행 프레젠테이션을 .
블랙 박스가 커서를 사용해야한다는 UDF에 대한 주장이 있습니다.
이 주장은 정확하지 않습니다.
엔진이 UDF 계산 단계 대신 전체 계획을 직렬화하는 이유를 설명하기위한 추가 사항.
내 이해는 현재 제한 사항이 순전히 특정 구현 세부 사항의 결과라는 것입니다. 병렬 처리를 사용하여 함수를 실행할 수없는 근본적인 이유는 없습니다.
특히, T-SQL 스칼라 함수는 별도의 T-SQL 컨텍스트 내에서 실행되므로 올바른 조작, 조정 및 종료 (특히 오류의 경우)가 상당히 복잡합니다.
마찬가지로 테이블 변수는 일반적으로 병렬 읽기 (쓰기는 아님)를 지원하지만 테이블 반환 함수에 의해 노출되는 테이블 변수는 구현 별 이유로 병렬 읽기를 지원할 수 없습니다. 신뢰할만한 답변을 제공하기 위해 소스 코드에 액세스 할 수있는 사람 (및 세부 정보를 공유 할 수있는 자유가있는 사람)이 필요합니다.
병렬 UDF 지원이 요청하기에 적합한 기능입니까?
물론, 충분히 강력한 사례를 만들 수 있다면. 내 자신의 느낌은 관련된 작업이 광범위 할 것이므로 귀하의 제안은 극도로 높은 기준 을 충족해야한다는 것 입니다. 예를 들어, 인라인 스칼라 함수를 제공하기위한 관련 (그리고 훨씬 간단한) 요청 은 큰 지원을 제공하지만 수년간 구현되지 않은 문제를 해결했습니다.
Microsoft 논문을 읽고 싶을 수도 있습니다.
... SQL Server 2017 이후 릴리스에서 Microsoft가 T-SQL 스칼라 함수 성능 문제를 해결하기 위해 취하는 접근법을 간략하게 설명합니다.
Froid의 목표는 개발자가 성능 저하없이 UDF 및 절차의 추상화를 사용할 수 있도록하는 것입니다. Froid는 가능할 때마다 명령형 프로그램을 동등한 관계형 대수 형태로 자동 변환하는 새로운 기술을 사용하여이 목표를 달성합니다. Froid는 명령형 코드 블록을 관계형 표현식으로 모델링하고 Apply 연산자를 사용하여이를 단일 표현식으로 체계적으로 결합하여 쿼리 최적화 프로그램이 효율적인 세트 지향 병렬 쿼리 계획 을 선택할 수 있도록합니다 .
(강조 광산)
인라인 스칼라 T-SQL 함수는 이제 SQL Server 2019에서 구현됩니다 .