2012-05-22 4 views
0

MySQL 데이터베이스 테이블 행에 150 개의 다른 작은 정수 값 (0에서 7까지의 범위)을 저장해야합니다. 이들 모두는 SELECT, INSERT 또는 UPDATE가있을 때마다 함께 읽고 씁니다. 테이블은 대부분 업데이트 될 것이고, 1 개의 삽입이 있고, 그 다음 행에 약 1000 개의 업데이트가있을 것입니다. DELETES 및 SELECTS는 실제로는 거의 발생하지 않습니다.tinyints 또는 하나의 varchar (300)?

성능면에서 150 개의 tinyint 열 또는 varchar (300)를 사용하는 것이 더 낫습니까?

결과 집합이 준비 될 때 MySQL이 150 컬럼 정의를 처리하는 데 걸리는 시간이 가장 중요합니다. 캐시 된 경우 이중 RAM이 필요합니다. 나는 수십만 개의 행을 가지므로 각 성능 비트가 중요합니다.

+1

150 개의 정수를 50 바이트 ('BINARY (50)'유형으로 저장)로 묶을 수 있으며 원하는 데이터에 비트를 돌릴 수 있습니다. 또는 그것들을 1 바이트 당 2 바이트 (BINARY (150))로 저장할 수 있습니까? – eggyal

+1

은 하나의 큰 필드에 저장하는 것이 (시간과 공간에서) 더 효율적이라고 가정 할 수 있습니다. 코드에서 데이터의 압축을 풀 때 그 이득 (또는 그 이상)을 잃지 않을 것이라고 생각하는 이유는 무엇입니까? – Toote

+0

나는 이것을했지만 나는 2000 년에 저장했다. 모두는 개별적으로 액세스해야하는 위치에 따라 다릅니다. 내 코드는 압축을 풀고 한 곳에서 포장 한 다음 산란 플롯을 작성하는 데 사용했습니다. 배열의 일종의 정렬이나 응용 프로그램에서 사용하는 유형 목록 (byte?)은 ascii 48에서 54와 같은 문자 데이터가 아닌 한 문자보다 낫습니다. –

답변

2

바이트 당 하나씩 이진 열에 저장할 것입니다. 데이터 세트는 메모리에 쉽게 들어가야합니다 (150b * 500k = 75Mb). 바이트 배열을 후행 처리하는 오버 헤드가 쿼리에 대한 열을 사용하는 db 오버 헤드와 선택하는 것보다 많을 것이라고 생각하지 않습니다. INSERT와 UPDATE는 DB에서 파싱하는데 걸리는 시간과 함께 생성하기가 불편하다. 차이는 아마도 밀리 초 범위에있을 것입니다. 따라서 응용 프로그램 끝에서 디코딩하는 것이 의미가 있습니다.

+0

모든 필드는 함께 읽거나 업데이트됩니다. 분명히, 나는 문자열 연결을 사용하여 UPDATE 문을 만들 것이다. –

+0

바이트 배열을 후 처리하는 오버 헤드가 쿼리 및 선택을 위해 열을 사용하는 db 오버 헤드보다 많을 것이라고 상상할 수 없습니다. 어쩌면'SELECT * FROM'이 효과적 일지 모르지만 INSERT와 UPDATE는 DB에서 파싱하는데 걸리는 시간과 함께 생성하기에는 못생긴 일입니다. 차이는 아마도 밀리 초 범위에있을 것입니다. 따라서 응용 프로그램 끝에서 디코딩하는 것이 의미가 있습니다. 필드는 어떻게 거기에 저장됩니까? 그리고 데이터 세트는 메모리에 쉽게 들어가야합니다 (150b * 500k = 75Mb). –

+0

내 시스템은 주로 업데이트입니다. 150 개의 필드를 가진 UPDATE 문을 구문 분석하는 것은 매우 느릴 수 있으므로 올바른 방법입니다. 바이너리를 사용하는 것이 좋습니다. 이것은 내가 찾고 있었던 바로 그 것이다. 진짜 대답으로 의견을 게시하여 받아 들일 수 있도록하겠습니다. –