올바른 MySQL 키 쌍 인덱스 선택

최근에 제 임무는 MySQL 테이블을 만드는 것입니다. 그 주요 목적은 한 쌍의 속성을 통해 기록을 전문적으로 찾는 것입니다.어떤 사람들은 이것이 매우 간단한 표라고 말할 수 있지만, 나는 성능 우선순위를 정하기 위해 색인을 도입하는 가장 좋은 방법이 의심스럽다.NosQL 엔진에서 실행하는 것이 더 빠를 수 있다는 것을 알지만, 이것은 본문의 주제가 아닙니다.
나는 이 두 속성을 연결해야 한다는 것을 알고 있지만, 나는 무엇이 더 좋은지 의심스럽다. SQL 키로 인덱스를 할까요, 아니면 해시 알고리즘 (md5) 을 할까요?MySQL은 유사한 해시 알고리즘을 사용했거나 심지어md5보다 더 빨랐습니까?나는 구글에서 검색을 해 보았지만, 실제로는 내가 뚜렷한 답안을 찾지 못해서 놀랐다.
나는 나에게 답을 줄 수 있는 기준이 필요하다. 그래서 나는 기준을 짰다. 그래서 본고의 목표는 성능 결과를 보여주고 결론을 얻는 것이다.비교를 하기 위해서, 나는 또 하나의 테이블의 성능을 검사하고 싶다. 이 테이블의 인덱스는 각각 속성에 분배된다.총 3개의 표가 기준 테스트를 진행해야 한다.
표 1. 단일 인덱스

CREATE TABLE `no_indexes` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `attribute_a` varchar(255) NOT NULL,
  `attribute_b` varchar(255) NOT NULL,
  `created_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `attribute_a` (`attribute_a`),
  KEY `attribute_b` (`attribute_b`)
) ENGINE=InnoDB AUTO_INCREMENT=50001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

표 키패어 인덱스

CREATE TABLE `keypair_index` (
  `attribute_a` varchar(255) NOT NULL,
  `attribute_b` varchar(255) NOT NULL,
  `created_at` timestamp NULL DEFAULT NULL,
  KEY `keypair_index_index` (`attribute_a`,`attribute_b`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

표 해시 인덱스

CREATE TABLE `hash_index` (
  `hash` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
  `attribute_a` varchar(255) NOT NULL,
  `attribute_b` varchar(255) NOT NULL,
  `created_at` timestamp NULL DEFAULT NULL
  KEY `hash_index_hash_index` (`hash`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

기본 테스트의 스크립트는 PHP7.2로 작성되었습니다(Linux에서 실행되며 MySQL 5.7.33 사용).첫 번째 테스트는 표마다 같은 수량의 기록을 만들고 무작위로 생성된 값으로 필드를 채운다. 즉 attribute_a는 네 개의 다른 값이 있고 attribute_b는 모든 다른 값이 있다.hash_index표에 생성된 모든 기록은 산열(md5 알고리즘 사용)을 계산해야 하며, 산열은 attribute_a와 attribute_b의 문자열로 직렬로 구성되어 있음을 주의하십시오.이 해시는 PHP 또는 MySQL에서 생성할 수 있습니다.
테스트는 결과가 일치할 수 있도록 여러 차례 진행되었다.
여러 삽입을 실행한 데이텀 시간 결과(ms):

빠르게 보면 hash_index표가 기록을 삽입할 때 성능이 가장 나쁜 것 같다.하지만 사실은 당신의 책상 위에 5만 개의 기록이 넘을 계획이라면 가장 좋은 성능을 제공할 것이다!이는 비례인자가 가장 낮기 때문이다(낮을수록 좋다). 이는 다른 표보다 비례가 더 좋고 어떤 점에서 일정 수량의 기록에 도달하면 그 표현이 individual_indexes표보다 우수하다는 것을 의미한다.10k기록을 삽입했을 때 keypair_index표는 괜찮아 보이기 시작했지만 50k가 넘는 기록이 존재하면 다른 표보다 훨씬 느릴 것이 분명하다.만약 당신이 대량의 기록을 가지고 규모를 확대할 계획이라면 이곳의 승자는 틀림없이 hash_index표일 것이다.
다음은 검색의 읽기 속도를 테스트하고 싶습니다. 이것은 저에게 가장 중요한 성능 지표입니다.스크립트는 기록을 만드는 것과 같은 방식으로 검색을 시도합니다. 무작위 값은 attribute_a 이고, MySQL 캐시를 사용하지 않습니다. (끊임없이 업데이트되는 생산 테이블을 모의하기 위해서입니다.)attribute_b표에 대해서는 표지표에 기록된 내용이기 때문에 읽기(선택)마다 MD5 해시를 계산해야 한다는 것을 주의하십시오.
테이블당 10k 검색의 기준 시간 결과(밀리초):

각 레벨hash_index 테이블에서 가장 좋은 성능과 확장성을 제공한다는 것은 명백하다.마찬가지로 가장 작은 비례 인자(낮을수록 좋다)는 1.05(!)대형 테이블에서 이 계수의 성능을 표시하는데 주의해야 할 것은 B-트리 구조의 성질 때문에 이 계수는 기록량이 증가함에 따라 약간 증가한다.나는 심지어 내가 다른 책상을 이번 토론에 가져가야 한다고 생각하지 않는다.
결론: 대량의 검색을 실행하는 테이블을 원한다면, 특히 두 개 이상의 속성을 조합한 테이블을 원하고, 확장성이 좋으면, 키 대 MySQL 인덱스보다 해시 인덱스가 더 빨리 작동할 것입니다.
로그표 같은 일을 계획한다면, 검색 동작이 매우 적고, 기록 수량도 매우 적기 때문에, 키를 사용하는 것은 색인에 가치가 있을 수 있지만, 장기적으로 보면, 나는 항상 해시 색인을 사용한다.