저장 프로 시저에서 임시 테이블의 varchar(255)모든 varchar필드를 사용 하는 것에 대한 아내의 작업에 대한 토론이 있습니다 . 기본적으로 한 캠프는 255를 사용하려고합니다. 정의가 변경 되어도 항상 작동하기 때문에 다른 캠프는 잠재적 인 성능 향상을 위해 소스 테이블의 크기를 고수하려고합니다.
퍼포먼스 캠프가 맞습니까? 다른 의미가 있습니까? 그들은 SQL Server를 사용하고 있습니다.
답변
임시 테이블을 사용하는 방법에 따라 데이터 잘림 문제가 발생할 수 있습니다.
이 예제는 약간 고안되었지만 내 요점을 보여줍니다. 예:
- 사용자 테이블 열은 varchar (50)입니다.
- 임시 테이블 열은 varchar (255)입니다.
- 사용자 테이블의 해당 열에 45자가있는 레코드가 있습니다.
- 절차에서 임시 테이블을 사용자 테이블에 병합하기 전에 해당 열의 끝에 ‘-for win’을 연결하십시오.
임시 테이블은 길이가 59 인 새 varchar 값을 기꺼이 받아들입니다. 그러나 사용자 테이블은 그럴 수 없었습니다. 프로 시저에서이를 처리하는 방법에 따라 잘림 또는 오류가 발생할 수 있습니다.
이러한 문제를 문서화하고 설명하지 않으면 절차가 예기치 않은 방식으로 수행 될 수 있습니다.
개인적으로, 나는이 질문에 대한 답이 100 % 정확한 것이라고 생각하지 않습니다. 실제로 임시 테이블을 사용하는 방법에 따라 다릅니다.
도움이 되었기를 바랍니다
답변
저장 프로 시저에서 임시 테이블의
varchar(255)모든varchar필드에 사용
실제 필드 길이를 사용하는 것에 기대어 있습니다.
나는 최근에 MySQL (SQL Server가 비슷하다고 가정한다) 임시 테이블이 각 varchar열에 가능한 최대 길이를 저장하기에 충분한 메모리를 할당한다는 것을 읽었습니다 … varchar모든 필드에 필요한 메모리의 200 % -500 %를 할당하는 체계적인 접근 저장 프로시 저는 시스템 리소스를 불필요하게 사용하는 것처럼 보입니다. 이러한 임시 테이블을 작성하는 데 상당한 양의 메모리를 사용하는 경우, 캐싱에 사용중인 메모리를 불필요하게 청구하여 저장 프로 시저가 완료된 후에도 나중에 언젠가 서버에 더 많은 작업을 작성하게됩니다.
편집 : Bill Karwin의 답변 참조 : https : //.com/questions/1962310/importance-of-varchar-length-in-mysql-table