6
동적 행을 끝으로 이동하는 경우 데이터를 가져 오는 속도에 차이가 있습니까?텍스트 열을 끝쪽으로 이동해야합니까?
예 : int, int, int, text가 int보다 낫습니다. text int?
내지도에서이 사실에 대해 알려주 었는데, 인터넷에서 이러한 정보가 어떻게 발생하지 않았습니까? 도와주세요 ?
A
답변
3
이것은 데이터 정렬 때문입니다. INT은 4 바이트를 차지하므로 32 비트 (4 바이트에 해당) 프로세서는 4 바이트 시퀀스의 데이터로 작동합니다. 프로세서에 가장 적합한 순서로 데이터를 추출 할 수있게되면 결과가 빨라지고 성능이 향상됩니다.
참조 : 이제 http://en.wikipedia.org/wiki/Data_structure_alignment
이 종종 특정 컴파일러는 일반적으로 4 바이트의 특정 멤버를 예약 바이트 정렬을 추가하여 데이터 구조를 최적화하기 때문에 (통신 채널을 통한 데이터 전송에서 발견되는 문제). 그러나 MySQL은 NDBCLUSTER 엔진을 고려하여 4 바이트 정렬을 고려합니다. 즉, INT 값 사이에 TEXT 구조를 삽입하면 필요한 것보다 더 많은 데이터를 강제로 검색하게됩니다. 따라서
: 프로세서가 바로 TEXT의 크기에 대한 걱정없이 16 바이트 (네 INT)를 검색 할 수
INTINTINTINTTEXT가 INTINTTEXTINTINT보다 빨리 처리 할 것이다.
http://dev.mysql.com/doc/refman/5.5/en/storage-requirements.html
1
TEXT 및 BLOB 데이터를 컬럼 자체와 동일한 공간에 저장되지 않습니다
은 자세한 내용은 MySQL의 문서를 참조하십시오. 그들은이 목적을 위해 예비 된 특별한 공간에 저장됩니다.
이 열은 항상 이고 검색 속도는 느리며이지만 느린 속도는 시스템 튜닝 및 데이터로드에 따라 상당히 다릅니다. 때로는 관련성이 없으며 때로는 심각한 타격을 일으킬 수 있습니다. TEXT 필드 위에 짧은 VARCHAR 필드를 사용해야합니다. 관리 할 수 있으면 blob 필드의 훨씬 긴 길이가 무료로 제공되지 않습니다.
, TEXT 항목은 대부분의 경우보다 VARCHAR들이 현저하게 작은 실제 데이터에 대한 포인터로 행에 저장된다. 선택하지 않으면로드되지 않으며 데이터를 어셈블 링하는 데 필요한 추가 검색이 발생하지 않습니다.
이것이 MySQL 버전과 튜닝에 적용되도록하려면 대표 데이터로 가득 찬 두 개의 큰 테이블을 작성하고 직접 벤치 마크하십시오.
성능 차이를 실제로 측정 할 수 있다면 * 매우 * 놀랄 것입니다. –