이론서나 관련 내용에서는 INT 형이 VARCHAR 형보다 빠르다고 한다. 이 부분에 대해서는 동의~
하지만 문제는 과연 얼마나 빠르냐? 라는 것이 궁금해서 호작질을 시작했다.
[목적]
INT 형과 VARCHAR 의 속도 차이를 알아본다.
INT 형 검색이 속도가 빨라 VARCHAR 데이터를 숫자형으로 나눠서 검색을 하는 것이 더 효율적인지를 알아봄
[실험방법]
캐쉬를 사용하지 않은 상테에서 각 단계별로 5회 / 회당 1000번 랜덤한 데이터를 조회한다. 각회당 5초의 시간을 쉬어준다.
결과를 평균내어 소수점 4자리에서 반올림하여 사용한다.
[데이터]
01010000000 ~ 01099999999 의 데이터(전화번호) 중복되지 않는 랜덤한 데이터를 10만개, 100만개, 1000만개 단위로 입력
[테이블 구조]
[테스트 서버]
하지만 문제는 과연 얼마나 빠르냐? 라는 것이 궁금해서 호작질을 시작했다.
[목적]
INT 형과 VARCHAR 의 속도 차이를 알아본다.
INT 형 검색이 속도가 빨라 VARCHAR 데이터를 숫자형으로 나눠서 검색을 하는 것이 더 효율적인지를 알아봄
[실험방법]
캐쉬를 사용하지 않은 상테에서 각 단계별로 5회 / 회당 1000번 랜덤한 데이터를 조회한다. 각회당 5초의 시간을 쉬어준다.
결과를 평균내어 소수점 4자리에서 반올림하여 사용한다.
[데이터]
01010000000 ~ 01099999999 의 데이터(전화번호) 중복되지 않는 랜덤한 데이터를 10만개, 100만개, 1000만개 단위로 입력
[테이블 구조]
/* varchar 테이블 */ CREATE TABLE `test_n_10` ( `idx` bigint(20) NOT NULL auto_increment, `full_number` varchar(255) collate utf8_unicode_ci default NULL, `text` text collate utf8_unicode_ci, `etc` varchar(255) collate utf8_unicode_ci default NULL, `regdt` datetime default NULL, PRIMARY KEY (`idx`), KEY `NewIndex1` (`full_number`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
/* int 테이블 */ CREATE TABLE `test_sp_10` ( `idx` bigint(20) NOT NULL auto_increment, `num1` int(11) default NULL, `num2` int(11) default NULL, `num3` int(11) default NULL, `full_number` varchar(255) collate utf8_unicode_ci default NULL, `text` text collate utf8_unicode_ci, `etc` varchar(255) collate utf8_unicode_ci default NULL, `regdt` datetime default NULL, PRIMARY KEY (`idx`), KEY `NewIndex1` (`num1`,`num2`,`num3`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
[테스트 서버]
운영체제 : centos 5.6 32bit, MySQL 5.0.77
사양 : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+, 메모리 2기가
[테스트 결과]
[분석]
varchar 10만개와 100만개의 검색 속도가 차이가 난다. 몇번이고 다시 해봐도 신기하게 10만개에서만 늦어지는 경우가 발생함. 이 부분에 대해서 원인 파악을 못함. 향후 다시 정비하여 해봐야 될꺼 같고
전체적으로 varchar 로 단일로 사용하는 것이 varchar 를 int 형으로 나누는 것 보다 효율이 좋다.
하지만. 테이블 각 필드의 자릿수가 너무 커서 그에 따른 속도의 변수가 있을지 몰라 정리하고 다시 테스트 해볼 예정임.
사양 : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+, 메모리 2기가
[테스트 결과]
1000개 랜덤한 숫자(매번계산) | 1000개 동일한 숫자(계산없음) | |||
데이터갯수 | VARCAHR | INT | VARCAHR | INT |
10만개 | 1.7208 | 0.2861 |
1.5073 | 0.2711 |
100만개 | 0.4708 | 1.1091 | 0.4107 | 0.9134 |
1000만개 | 2.7343 | 4.6725 | 1.5678 | 4.0113 |
[분석]
varchar 10만개와 100만개의 검색 속도가 차이가 난다. 몇번이고 다시 해봐도 신기하게 10만개에서만 늦어지는 경우가 발생함. 이 부분에 대해서 원인 파악을 못함. 향후 다시 정비하여 해봐야 될꺼 같고
전체적으로 varchar 로 단일로 사용하는 것이 varchar 를 int 형으로 나누는 것 보다 효율이 좋다.
하지만. 테이블 각 필드의 자릿수가 너무 커서 그에 따른 속도의 변수가 있을지 몰라 정리하고 다시 테스트 해볼 예정임.
반응형