기본 키인 MySQL-uuid와 기본 키인 int의 성능 측정 비교에 대한 자세한 설명

우연히 mysql 기본 키 유형이 varchar를 사용하여 UUID를 저장한다는 사실을 알게 되었습니다. query의 성능은 int 유형의 기본 키만큼 좋지 않습니다. 인터넷에서 검색하는 많은 정보는 이론적인 내용일 뿐이므로 실제 테스트를 위해 직접 코드를 작성했습니다. 아래 결과는 참고용일 뿐이며 신뢰할 수 있는 내용은 아닙니다.

기본 키 ID가 각각 varchar, bigint 및 auto-increase bigint를 사용하는 것을 제외하고 세 테이블의 필드는 모두 varchar 36비트입니다

데이터베이스: mysql5.5

테이블 유형: InnoDB

데이터량: 100W 항목

첫 번째 경우:

기본 키는 uuid 32비트를 사용합니다.

쿼리 문 1 실행: SELECT COUNT(id) FROM test_varchar;

쿼리 문 2 실행: SELECT * FROM test_varchar WHERE vname='00004629-b052-11e1-96aa-002655b28d7b ';

쿼리 문 3 실행: SELECT * FROM test_varchar WHERE id='00004599b05211e196aa002655b28d7b';

문 1에 소요되는 평균 시간은 2.7초입니다.

시간 명령문 2에서 소비된 평균 시간은 3초입니다.

명령문 3에서 소비된 평균 시간은 0초입니다(다자간 테스트, 조건에 기본 키 ID가 있는 한, 쿼리 속도는 밀리초 단위로 000을 표시합니다. 테스트의 ID 값에는 처음 100개가 포함됩니다. 쿼리 시간도 정확히 동일하며 밀리초는 000입니다.

두 번째 경우:

bigint가 사용됩니다. uuid_short()를 사용하여 데이터를 생성합니다. 데이터는 일련의 순수 숫자입니다(22461015967875697). (고정 기준 값이 더 크다는 점을 제외하면 자동 증가와 동일합니다.)

쿼리 문 1 실행: SELECT COUNT(id) FROM test_long;

쿼리 문 2 실행: SELECT * FROM test_long WHERE vname='d7f28a24-b053-11e1-96aa-002655b28d7b';

쿼리 문 3 실행: SELECT * FROM test_long WHERE id='22461015967875702';

에서 소비한 평균 시간 명령문 1은 1.2초입니다.

명령문 2는 평균 1.40초를 소비합니다.

명령문 3은 평균 0초를 소비합니다. 조건의 기본 키 ID, 쿼리 속도는 밀리초 수준이 모두 000으로 표시됩니다. 테스트된 ID 값의 범위는 처음 100부터 마지막 ​​900,000까지입니다. 쿼리 시간은 정확히 동일하며 밀리초 수준은 모두 000입니다.

세 번째 경우:

쿼리 문 1 실행: SELECT COUNT(id) FROM test_int;

쿼리 문 2 실행: SELECT * FROM test_int WHERE vname='c80f8427-b059-11e1-96aa-002655b28d7b ';

쿼리 문 3 실행: SELECT * FROM test_int WHERE id=900000;

기본 키는 자동 키를 사용합니다. mysql과 함께 제공되는 성장이며 데이터는 순수한 숫자(1, 2, 3, 4, 5...)입니다.

쿼리 문 1의 평균 소비 시간은 1.07초입니다.

쿼리 문 2의 평균 소비 시간은 1.31초입니다. 명령문 3은 0초입니다. (다자간 테스트, 조건에 기본 키 ID가 있는 한 밀리초 단위의 쿼리 속도는 000으로 표시됩니다. 테스트된 ID 값의 범위는 처음 100에서 900,000 이상입니다. 쿼리 시간은 정확히 동일하며 밀리초는 모두 000이 됩니다. )

요약: mysql InnoDB 기본 키의 자동 증가 성능이 더 높다는 것을 알 수 있습니다. . 작가는 스스로에게 이렇게 말합니다. 일반적인 프로젝트 개발에서는 SQL 문의 조건에 ID가 있는 사람이 대다수를 차지하고 ID가 없는 사람이 소수를 차지합니다. 위의 테스트에서는 조건문에 기본키 ID가 있는 한 기본키 유형에 관계없이 쿼리 시간이 정확히 동일하다는 것을 보여줍니다. 그러나 프로젝트의 모든 SQL 문에 조건에 ID가 있다고 보장할 수는 없습니다. 따라서 어떤 유형의 기본 키를 사용해야 하는지 이미 이해하셨으리라 믿습니다.

데이터베이스: mysql5.5

테이블 유형: MyISAM

데이터량 : 100만개

작성하는 단어 수를 줄이고 시간을 절약하기 위해 이번 테스트에 사용된 테이블과 SQL 문은 동일합니다. 위와 같이 여기에만 경과 시간을 기록합니다.

첫 번째 경우:

기본 키는 uuid 32비트를 사용합니다.

문 1의 평균 소비 시간은 0초입니다.

문 2의 평균 소비 시간은 0.53초입니다. 명령문 3은 0초입니다. (다자간 테스트, 조건에 기본 키 ID가 있는 한 밀리초 단위의 쿼리 속도는 000으로 표시됩니다. 테스트된 ID 값의 범위는 처음 100에서 900,000 이상입니다. . 쿼리 시간은 정확히 동일하며 밀리초는 모두 000입니다. )

두 번째 경우:

기본 키가 bigint를 사용합니다 , uuid_short()를 사용하여 데이터를 생성합니다. 데이터는 순수한 숫자의 시퀀스입니다(22461015967875697). (고정 기준 값이 더 크다는 점을 제외하면 자동 증가와 동일합니다.)

문 1의 평균 소비 시간은 0초입니다. 문 2의 평균 소비 시간은 입니다. : 0.51초;

문 3의 평균 소비 시간은 0초입니다. (다자간 테스트, 조건에 기본 키 ID가 있는 한 쿼리 속도는 밀리초 단위로 000을 표시합니다. 테스트된 ID 값 범위 처음 100부터 900,000 이상) 쿼리 시간은 정확히 동일하며, 밀리초 수준은 000입니다.)

세 번째 경우:

기본 키는 mysql 과 함께 제공되는 자동 증가를 사용하며 데이터는 순수한 숫자(1, 2, 3, 4, 5...)입니다.

문 1에서 소비한 평균 시간은 0초입니다.

문 2에서 소비한 평균 시간은 0.48초입니다.

문 3에서 소비한 평균 시간은 : 0초; (다중 당사자 테스트에서 조건에 기본 키 ID가 있는 한 밀리초 단위의 쿼리 속도는 000을 표시합니다. 테스트된 ID 값에는 처음 100개와 마지막 900,000개가 포함됩니다. 쿼리 시간은 정확히 같고, 밀리세컨드 수준은 000)

요약: mysql MyISAM 기본키의 자동 증가 성능은 다른 것보다 약간 우위에 있다는 것을 알 수 있다. 테스트 데이터가 100W 1000W라면 외래키 관련 쿼리도 있다면 이 장점은 더욱 커질 것이라고 생각합니다. 물론, 설계한 시스템의 데이터 양이 100만 개를 초과하지 않는다면 어떤 기본 키 유형을 사용하는지는 중요하지 않습니다. 제 테스트 컴퓨터는 노트북인데, 전문서버라면 100만대로 추정됩니다. mysql MyISAM의 테스트에서는 시간차를 전혀 측정할 수 없습니다.

위 내용은 기본 키인 MySQL-uuid와 기본 키인 int의 성능 측정 비교에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!