MAX 텍스트 또는보다 구체적이고 작은 유형 사용

그들이 볼 때 누군가가 내가 사용보고, 제안 테이블을 만들기위한 내 DDL 코드를 검토하고 있었다 VARCHAR(256)나는 것을, 나는 이름이든 같은, 아주 작은 것으로 예상 텍스트 필드를 항상 바로 사용 VARCHAR(MAX)및 링크 를 사용하는 이유 아무것도하지만, VARCHAR (최대 ) . 나는 그것을 읽었지만 2005 년에 중점을 두었으므로 날짜가 지난 것처럼 보였고 모든 텍스트 필드에서 행 당 최대 2GB를 할당 할 수있는 진정한 근거를 제시하지는 못했습니다.

성능, 저장소 등의 관점에서 VARCHAR(MAX)최신 버전의 SQL Server에 대해보다 구체적인 유형 을 사용할지 아니면 더 작은 유형을 결정해야 합니까? (예 : 2008, 2012, 2014)

항상 (n)varchar(max)텍스트 열에 사용해야 합니까?

아니.

SQL Server의 max경우 대안이없는 경우에만 데이터 유형을 지정해야합니다. 대신 올바른 기본 유형 ( varchar또는 nvarchar)을 선택하고 저장할 데이터에 적합한 명시 적 최대 길이를 지정해야합니다.

물리적 스토리지는 컬럼이 varchar(n)또는 로 입력되는지에 관계없이 동일 varchar(max)하므로 걱정하지 않아도됩니다.

모든 곳을 선택 하지 않는 이유는 (n)varchar(max)기능, 계획 품질 및 성능을 중심으로합니다.

철저한 목록은 실용적이지 않지만 다른 것들 중에서도 max열입니다.

풍모

• 최대 길이를 적용하려면 별도의 제약 조건이 필요합니다
• 인덱스의 키가 될 수 없습니다 (따라서 고유 제한 조건도 없음)
• 온라인 DDL을 방지 할 수 있음 (인덱스 재 구축 및 널이 아닌 새로운 열 추가 포함)
• columnstore와 같은 '최신'기능은 일반적으로 지원되지 않습니다.
• 보다 구체적인 기능 및 제한 사항은 제품 설명서를 참조하십시오. 일반적인 패턴은 max데이터 유형에 대한 어색한 제한과 제한이 있다는 것 입니다. 모든 제한 사항과 부작용이 기록되어있는 것은 아닙니다.

공연

• 잠재적으로 매우 큰 크기를 설명하기 위해 실행 엔진에서 특별한 처리가 필요합니다. 일반적으로 스트리밍 인터페이스와 함께 덜 효율적인 코드 경로를 사용합니다.
• 최대 2GB 크기의 데이터를 처리 할 수 있도록 준비 해야하는 외부 코드 (및 SSIS와 같은 다른 SQL Server 구성 요소)에 대해서도 예상치 못한 결과가 발생할 수 있습니다.
• 메모리 부여 계산에서 너비가 4000 바이트 인 것으로 가정합니다. 이로 인해 메모리 예약이 과도 해져 동시성이 제한되고 중요한 인덱스 및 데이터 페이지가 캐시 메모리에서 밀려납니다
• 몇 가지 중요한 성능 최적화 비활성화
• 잠금 기간을 연장 할 수 있음
• 옵티마이 저가 (비 동적) 탐색 계획을 선택하지 못하게 할 수 있음
• 필터가 스캔으로 푸시되지 않고 잔차로 검색되지 않도록 방지
• 변수 및 매개 변수도 max열 정의와 일치 하도록 입력 될 수 있으므로 tempdb 압력 및 경합 (버전에 따라 다름)을 증가시킬 수 있습니다

요약하면 불필요하게 max지정자를 사용하면 미묘하고 바람직하지 않은 부작용이 많으므로이 작업을 수행하는 것이 의미가 없습니다. 단일 선언을 사용하는 사소한 '편의성'은 일종의 보상이 아닙니다.

문맥에서 각 유형을 평가하고 올바른 기본 유형 ( varchar또는 nvarchar)과 적절한 명시 적 길이를 사용하십시오.

더 읽을 거리 :

• Remus Rusanu에 의한 varchar (max)와 varchar (n)의 성능 비교
• Craig Freedman의 커밋 된 큰 개체 읽기
• tempdb 용량 계획
• 분할 된 페이지와 전달 된 유령을 삭제합니다 (me)

이것은 편집증의 답변처럼 읽히지 만 스토리지 및 성능 고려 사항 만 이 아닙니다 .

데이터베이스 자체는 클라이언트를 제어하지 않으며 Entity Framework를 사용하여 트랜잭션을 캡슐화하고 매개 변수화 된 쿼리를 보장하는 .net 응용 프로그램에서만 데이터베이스를 사용하도록 설계된 경우에도 클라이언트가 항상 사용자 입력을 안전하게 삽입한다고 가정 할 수 없습니다. 체계적으로 사용 되므로 항상 사실임을 알 수 없습니다 .

이 작업을 수행하는 방법을 정확히 모르지만 모든 텍스트 필드를 작성 varchar(max)하여 클라이언트에 Bobby Tables 문제가 있거나 저장 프로 시저 매개 변수도 varchar(max)있는 경우 공격자가 더 쉽게 대처할 수 있습니다. 클라이언트가하지 말아야 할 일을 할 수있는 유효하지만 영리하게 악의적 인 매개 변수 값.

실제로 필요한 길이로 제한함으로써 , 당신은 이러한 영리한 공격으로부터 자신을 보호 하지 못합니다 (실제로 불려지는 것조차 확실하지 않습니다. 나는 단지 그것에 대해 읽은 것을 기억합니다). 계속해서 2GB 스크립트를 실행 해 봅니다. "