varchar (8000)보다 varchar (500)의 장점이 있습니까?

varchar (8000)보다 varchar (500)의 장점이 있습니까?

---

나는 MSDN 포럼과 여기에서 이것을 읽었으며 아직 명확하지 않습니다. 나는 이것이 옳다고 생각한다. Varchar (max)는 텍스트 데이터 유형으로 저장되므로 단점이 있습니다. 따라서 귀하의 필드가 8000 자 미만이 될 것이라고 가정 해 보겠습니다. 내 데이터베이스 테이블의 BusinessName 필드와 같습니다. 실제로 비즈니스 이름은 아마도 항상 500 자 미만일 것입니다 (내 모자에서 숫자를 가져옴). 내가 실행하는 많은 varchar 필드가 8k 문자 수에 훨씬 못 미치는 것 같습니다.

그렇다면 해당 필드를 varchar (8000) 대신 varchar (500)로 만들어야합니까? 내가 이해하는 SQL에서이 둘 사이에는 차이가 없습니다. 따라서 삶을 쉽게 만들기 위해 모든 varchar 필드를 varchar (8000)로 정의하고 싶습니다. 단점이 있습니까?

관련 : varchar 열의 크기 (이 질문에 대한 답이 없다고 생각했습니다).

---

처리 관점에서 varchar (8000)과 varchar (500)을 사용하는 것은 차이가 없습니다. 필드가 보유해야하는 최대 길이를 정의하고 varchar를 해당 길이로 만드는 것이 "좋은 방법"에 가깝습니다. 데이터 유효성 검사를 지원하는 데 사용할 수 있습니다. 예를 들어, 주 약자를 2 자로 만들거나 우편 번호를 5 또는 9 자로 만듭니다. 이전에는 데이터가 필드 길이가 중요한 다른 시스템 또는 사용자 인터페이스 (예 : 메인 프레임 플랫 파일 데이터 세트)와 상호 작용할 때 더 중요한 구분 이었지만, 요즘에는 다른 무엇보다 습관이 더 많다고 생각합니다.

---

이것이 차이를 만들 수있는 한 가지 예는 트리거 이후에 ​​테이블에 행 버전 관리 정보를 추가하지 않는 성능 최적화를 방지 할 수 있다는 것입니다.

여기에서는 SQL Kiwi에서 다룹니다.

저장된 데이터의 실제 크기는 중요하지 않습니다. 중요한 것은 잠재적 인 크기입니다.

마찬가지로 2016 년부터 메모리 최적화 테이블을 사용하는 경우 LOB 열 또는 잠재적으로 인 로우 제한을 초과 할 수 있지만 패널티가있는 열 너비 조합을 사용할 수있었습니다.

(최대) 열은 항상 행 외부에 저장됩니다. 다른 열의 경우 테이블 정의의 데이터 행 크기가 8,060 바이트를 초과 할 수있는 경우 SQL Server는 가장 큰 가변 길이 열을 행 외부로 푸시합니다. 다시 말하지만 여기에 저장하는 데이터의 양에 의존하지 않습니다.

이는 메모리 소비 및 성능에 큰 부정적인 영향을 미칠 수 있습니다.

열 너비를 과도하게 선언하면 큰 차이가 발생할 수있는 또 다른 경우는 테이블이 SSIS를 사용하여 처리되는 경우입니다. 가변 길이 (비 BLOB) 열에 할당 된 메모리는 실행 트리의 각 행에 대해 고정되며 열의 선언 된 최대 길이에 따라 달라지며 메모리 버퍼를 비효율적으로 사용할 수 있습니다 (예) . SSIS 패키지 개발자는 소스보다 더 작은 열 크기를 선언 할 수 있지만이 분석은 먼저 수행하고 적용하는 것이 가장 좋습니다.

SQL Server 엔진 자체에서 비슷한 경우는 SORT작업 에 할당 할 메모리 부여를 계산할 때 SQL Server에서 varchar(x)열이 평균적으로 x/2바이트를 소비 한다고 가정하는 것입니다 .

대부분의 varchar열이 그보다 가득 차면 sort작업이 tempdb.

귀하의 경우 varchar열이 8000바이트 로 선언 되었지만 실제로 내용이 훨씬 적은 경우 쿼리에 필요하지 않은 메모리가 할당되며 이는 분명히 비효율적이며 메모리 부여를 기다릴 수 있습니다.

여기에서 다운로드 할 수있는 SQL Workshops 웹 캐스트 1의 Part 2에서 다루 거나 아래를 참조하십시오.

use tempdb;

CREATE TABLE T(
id INT IDENTITY(1,1) PRIMARY KEY,
number int,
name8000 VARCHAR(8000),
name500 VARCHAR(500))

INSERT INTO  T 
(number,name8000,name500)
SELECT number, name, name /*<--Same contents in both cols*/
FROM master..spt_values

SELECT id,name500
FROM T
ORDER BY number

SELECT id,name8000
FROM T
ORDER BY number

---

모범 사례와는 별도로 (BBlake의 답변)

• DDL에서 최대 행 크기 (8060) 바이트 및 인덱스 너비 (900 바이트)에 대한 경고가 표시됩니다.
• 이 제한을 초과하면 DML이 죽습니다.
• ANSI PADDING ON이 기본값이므로 전체 공백을 저장할 수 있습니다.

---

There are some disadvantages to large columns that are a bit less obvious and might catch you a little later:

• All columns you use in an INDEX - must not exceed 900 bytes
• All the columns in an ORDER BY clause may not exceed 8060 bytes. This is a bit difficult to grasp since this only applies to some columns. See SQL 2008 R2 Row size limit exceeded for details)
• If the total row size exceeds 8060 bytes, you get a "page spill" for that row. This might affect performance (A page is an allocation unit in SQLServer and is fixed at 8000 bytes+some overhead. Exceeding this will not be severe, but it's noticable and you should try to avoid it if you easily can)
• Many other internal datastructures, buffers and last-not-least your own varaibles and table-variables all need to mirror these sizes. With excessive sizes, excessive memory allocation can affect performance

As a general rule, try to be conservative with the column width. If it becomes a problem, you can easily expand it to fit the needs. If you notice memory issues later, shrinking a wide column later may become impossible without losing data and you won't know where to begin.

In your example of the business names, think about where you get to display them. Is there really space for 500 characters?? If not, there is little point in storing them as such. http://en.wikipedia.org/wiki/List_of_companies_of_the_United_States lists some company names and the max is about 50 characters. So I'd use 100 for the column max. Maybe more like 80.

---

Ideally you'd want to go smaller than that, down to a reasonably sized length (500 isn't reasonably sized) and make sure the client validation catches when the data is going to be too large and send a useful error.

varchar가 실제로 사용되지 않은 공간을 위해 데이터베이스에 공간을 예약하지는 않지만 데이터베이스 행이 일부 바이트 수 (정확한 수를 기억하지 않음)보다 넓고 실제로 버려지는 SQL Server 버전을 기억합니다. 적합하지 않은 데이터가 무엇이든. 이러한 바이트 중 특정 수는 SQL Server 내부의 항목을 위해 예약되었습니다.

참고 URL : https://stackoverflow.com/questions/2009694/is-there-an-advantage-to-varchar500-over-varchar8000