MySQL에서 자동 증가 ID 기본 키와 UUID를 기본 키로 사용하는 경우의 장단점을 비교하는 세부 프로세스(100만에서 1000만 개의 테이블 레코드 테스트)

테스트 이유

개발 동료가 기본 키가 uuid인 프레임워크를 만들었는데, 나는 그에게 mysql이 uuid를 사용하지 말고 자동 증가 기본 키를 사용하는 것이 더 효율적인 것은 아니라고 제안했습니다. innodb의 인덱스 기능은 id를 자동증가시키는 기능이라 기본키를 만드는 것이 가장 효율적이라고 했고, 실제 사례를 통해 설득하기 위해 상세한 테스트를 준비했습니다.

인터넷 회사라면 사용자 테이블이 있어야 하는데, UC_USER 사용자 테이블은 기본적으로 수백만개 따라서 이 표를 바탕으로 준시험자료를 바탕으로 시험을 진행한다.

현재 테스트 과정은 제가 생각하는 여러 종류의 SQL 테스트가 다면적이고 흔히 사용되는 테스트입니다. 완벽하지 않을 수도 있습니다. 보다 완벽한 테스트 계획이나 테스트 SQL 문을 제안하기 위해 메시지를 남겨주시면 됩니다.

테이블 및 데이터 준비

UC_USER, 기본 키로 자동 증가 ID, 테이블 구조는 다음과 유사합니다.

CREATE TABLE `UC_USER` (
   `ID` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
   `USER_NAME` varchar(100) DEFAULT NULL COMMENT '用户名',
   `USER_PWD` varchar(200) DEFAULT NULL COMMENT '密码',
   `BIRTHDAY` datetime DEFAULT NULL COMMENT '生日',
   `NAME` varchar(200) DEFAULT NULL COMMENT '姓名',
   `USER_ICON` varchar(500) DEFAULT NULL COMMENT '头像图片',
   `SEX` char(1) DEFAULT NULL COMMENT '性别, 1:男，2:女，3：保密',
   `NICKNAME` varchar(200) DEFAULT NULL COMMENT '昵称',
   `STAT` varchar(10) DEFAULT NULL COMMENT '用户状态，01:正常，02:冻结',
   `USER_MALL` bigint(20) DEFAULT NULL COMMENT '当前所属MALL',
   `LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT '最后登录时间',
   `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT '最后登录IP',
   `SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT '来源的联合登录',
   `EMAIL` varchar(200) DEFAULT NULL COMMENT '邮箱',
   `MOBILE` varchar(50) DEFAULT NULL COMMENT '手机',
   `IS_DEL` char(1) DEFAULT '0' COMMENT '是否删除',
   `IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定邮箱',
   `IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定手机',
   `CREATER` bigint(20) DEFAULT NULL COMMENT '创建人',
   `CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间',
   `UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '修改日期',
   `PWD_INTENSITY` char(1) DEFAULT NULL COMMENT '密码强度',
   `MOBILE_TGC` char(64) DEFAULT NULL COMMENT '手机登录标识',
   `MAC` char(64) DEFAULT NULL COMMENT 'mac地址',
   `SOURCE` char(1) DEFAULT '0' COMMENT '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:管理系统, 0:未知',
   `ACTIVATE` char(1) DEFAULT '1' COMMENT '激活，1：激活，0：未激活',
   `ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT '激活类型，0：自动，1：手动',
   PRIMARY KEY (`ID`),
   UNIQUE KEY `USER_NAME` (`USER_NAME`),
   KEY `MOBILE` (`MOBILE`),
   KEY `IDX_MOBILE_TGC` (`MOBILE_TGC`,`ID`),
   KEY `IDX_EMAIL` (`EMAIL`,`ID`),
   KEY `IDX_CREATE_DATE` (`CREATE_DATE`,`ID`),
   KEY `IDX_UPDATE_DATE` (`UPDATE_DATE`)
 ) ENGINE=InnoDB AUTO_INCREMENT=7122681 DEFAULT CHARSET=utf8 COMMENT='用户表'

UC_USER_PK_VARCHAR 테이블, 기본 키로 문자열 ID, uuid 사용

티바디>테이블>

2. 500W데이터 테스트

2.1 500W 입력, 자동 증가 ID 절반 저장 디스크 공간

두 테이블의 데이터 볼륨 결정

CREATE TABLE `UC_USER_PK_VARCHAR_1` (
  `ID` varchar(36) CHARACTER SET utf8mb4 NOT NULL DEFAULT '0' COMMENT '主键',
   `USER_NAME` varchar(100) DEFAULT NULL COMMENT '用户名',
   `USER_PWD` varchar(200) DEFAULT NULL COMMENT '密码',
   `BIRTHDAY` datetime DEFAULT NULL COMMENT '生日',
   `NAME` varchar(200) DEFAULT NULL COMMENT '姓名',
   `USER_ICON` varchar(500) DEFAULT NULL COMMENT '头像图片',
   `SEX` char(1) DEFAULT NULL COMMENT '性别, 1:男，2:女，3：保密',
   `NICKNAME` varchar(200) DEFAULT NULL COMMENT '昵称',
   `STAT` varchar(10) DEFAULT NULL COMMENT '用户状态，01:正常，02:冻结',
   `USER_MALL` bigint(20) DEFAULT NULL COMMENT '当前所属MALL',
   `LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT '最后登录时间',
   `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT '最后登录IP',
   `SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT '来源的联合登录',
   `EMAIL` varchar(200) DEFAULT NULL COMMENT '邮箱',
   `MOBILE` varchar(50) DEFAULT NULL COMMENT '手机',
   `IS_DEL` char(1) DEFAULT '0' COMMENT '是否删除',
   `IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定邮箱',
   `IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定手机',
   `CREATER` bigint(20) DEFAULT NULL COMMENT '创建人',
   `CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间',
   `UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '修改日期',
   `PWD_INTENSITY` char(1) DEFAULT NULL COMMENT '密码强度',
   `MOBILE_TGC` char(64) DEFAULT NULL COMMENT '手机登录标识',
   `MAC` char(64) DEFAULT NULL COMMENT 'mac地址',
   `SOURCE` char(1) DEFAULT '0' COMMENT '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:管理系统, 0:未知',
   `ACTIVATE` char(1) DEFAULT '1' COMMENT '激活，1：激活，0：未激活',
   `ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT '激活类型，0：自动，1：手动',
   PRIMARY KEY (`ID`),
   UNIQUE KEY `USER_NAME` (`USER_NAME`),
   KEY `MOBILE` (`MOBILE`),
   KEY `IDX_MOBILE_TGC` (`MOBILE_TGC`,`ID`),
   KEY `IDX_EMAIL` (`EMAIL`,`ID`),
   KEY `IDX_CREATE_DATE` (`CREATE_DATE`,`ID`),
   KEY `IDX_UPDATE_DATE` (`UPDATE_DATE`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表';

CREATE TABLE `UC_USER_PK_VARCHAR_1`(
`ID` varchar(36) 문자 집합 utf8mb4 NOT NULL 기본값 '0' COMMENT '기본 키', `USER_NAME` varchar(100) 기본 NULL 코멘트 '사용자 이름',
`USER_PWD` varchar(200) 기본 NULL 코멘트 '비밀번호',
`BIRTHDAY` 날짜/시간 기본 NULL 코멘트 '생일', `NAME` varchar(200) DEFAULT NULL COMMENT '이름',
`USER_ICON` varchar(500) DEFAULT NULL COMMENT '아바타 사진',
`SEX` char(1) DEFAULT NULL COMMENT '성별, 1: 남성, 2: 여성, 3: 기밀',
`NICKNAME` varchar(200) DEFAULT NULL COMMENT '닉네임',
`STAT` varchar(10) DEFAULT NULL COMMENT ' 사용자 상태, 01: 정상, 02: 동결',
`USER_MALL` bigint(20) DEFAULT NULL COMMENT '현재 MALL',
`LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT '마지막 로그인 시간',
/> `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT '마지막 로그인 IP',
`SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT '공동 로그인 소스',
`EMAIL` varchar( 200) DEFAULT NULL COMMENT '사서함',
`MOBILE` varchar(50) DEFAULT NULL COMMENT '휴대전화',
`IS_DEL` char(1) DEFAULT '0' COMMENT '삭제 여부',
`IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT '이메일 주소 결합 여부',
`IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT '휴대폰 결합 여부',
`CREATER` bigint (20) DEFAULT NULL COMMENT '작성자',
`CREATE_DATE` 날짜 시간 DEFAULT CURRENT_TIMESTAMP COMMENT '등록 시간',
`UPDATE_DATE` 날짜 시간 DEFAULT CURRENT_TIMESTAMP COMMENT '수정 날짜',
`PWD_INTENSITY` char(1) DEFAULT NULL COMMENT '비밀번호 강도',
`MOBILE_TGC` char(64) DEFAULT NULL COMMENT '휴대폰 로그인 ID',
`MAC` char(64 ) DEFAULT NULL COMMENT 'mac 주소' ,
`SOURCE` char(1) DEFAULT '0' COMMENT '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:관리 시스템, 0:알 수 없음 ',
`ACTIVATE `char(1) DEFAULT '1' COMMENT '활성화, 1: 활성화됨, 0: 활성화되지 않음',
`ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT '활성화 유형 , 0: 자동, 1: 수동 ',
기본 키(`ID`),
고유 키 `USER_NAME`(`USER_NAME`),
키 `MOBILE`(`MOBILE`) ,
키 `IDX_MOBILE_TGC`(`MOBILE_TGC`,`ID`),
키 `IDX_EMAIL`(`EMAIL`,`ID`),
키 `IDX_CREATE_DATE`(`CREATE_DATE`, `ID`),
KEY `IDX_UPDATE_DATE` (`UPDATE_DATE`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='사용자 테이블';

# 自增id为主键的表

mysql> select count(1) from UC_USER;

+----------+

| count(1) |

+----------+

|   5720112 |

+----------+

1 row in set (0.00 sec)

 

mysql>

 

# uuid为主键的表

mysql> select count(1) from  UC_USER_PK_VARCHAR_1;

+----------+

| count(1) |

+----------+

|   5720112 |

+----------+

1 row in set (1.91 sec)

# 기본 키로 자동 증가 ID가 있는 테이블

mysql> UC_USER에서 count(1) 선택;

+----------+

主键类型	数据文件大小	占据容量
自增ID	-rw-rw---- 1 mysql mysql 2.5G Aug 11  18:29 UC_USER.ibd	2.5 G
UUID	-rw-rw---- 1 mysql mysql 5.4G Aug 15  15:11 UC_USER_PK_VARCHAR_1.ibd	5.4 G

| 개수( 1) |

+----------+

| 5720112 |

+------- ---+세트의 1행(0.00초) mysql> # uuid가 기본인 테이블 key mysql> UC_USER_PK_VARCHAR_1에서 count(1) 선택;

主键类型	SQL语句	执行时间 (秒)
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER` t WHERE t.`MOBILE` ='14782121512';	0.118
UUID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` ='14782121512';	0.117
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER` t WHERE t.`MOBILE` IN( '14782121512','13761460105');	0.049
UUID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE`  IN('14782121512','13761460105');	0.040
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:36' ;	0.139
UUID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:43' ;	0.126

+----------+| +--- -------+| 5720112 |+--------+1행 in set (1.91 sec)

차지하는 공간 용량으로 판단하면 자동 증분 ID는 기존보다 절반 정도 작습니다. UUID.

기본 키 유형	데이터 파일 크기	점유 용량 강함>
자체 증가 ID	-rw -rw---- 1 mysql mysql 2.5G 8월 11일 18:29 UC_USER.ibd	2.5G
UUID	-rw-rw---- 1 mysql mysql 5.4G 8월 15일 15: 11 UC_USER_PK_VARCHAR_1.ibd	5.4G

2.2 단일 데이터를 인덱싱하고 id를 id만큼 증가시킵니다. 그리고 uuid별로 다르지 않습니다자동 증가 ID

0.040

기본 키 유형	SQL 문 td>	실행 시간(초)
SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`MOBILE` ='14782121512';	0.118
UUID	선택 SQL_NO_CACHE t.* FROM 테스트. `UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` ='14782121512';	0.117
자동 증가 ID	SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`MOBILE` IN( '14782121512','13761460105');	0.049
UUID td>	SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` IN('14782121512','13761460105');
자동 증가 ID	SELECT SQL_NO_CACHE t .* FROM 테스트.`UC_USER` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:36' ;	0.139
UUID	SELECT SQL_NO_CACHE t.* FROM test .`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:43' ;	0.126

2.3 Scopelike쿼리, 자동 증가 ID는 UUID

SELECT SQL_NO_CACHE t .* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > '2016-08-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC 20개 제한; tr>

主键类型	SQL语句	执行时间 (秒)
（1）模糊范围查询1000条数据，自增ID性能要好于UUID
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER` t WHERE t.`MOBILE` LIKE '147%' LIMIT 1000;	1.784
UUID	SELECT  SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` LIKE  '147%' LIMIT 1000;	3.196
（2）日期范围查询20条数据，自增ID稍微弱于UUID
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER` t WHERE t.`CREATE_DATE` > '2016-08-01 10:26:36' ORDER BY  t.`UPDATE_DATE` DESC LIMIT 20;	0.601
UUID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > '2016-08-01 10:26:36'  ORDER BY t.`UPDATE_DATE` DESC LIMIT 20;	0.543
（3）范围查询200条数据，自增ID性能要好于UUID
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36' ORDER BY  t.`UPDATE_DATE` DESC LIMIT 200;	2.314
UUID	SELECT  SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE`  > '2016-07-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 200;	3.229
范围查询总数量，自增ID要好于UUID
自增ID	SELECT SQL_NO_CACHE COUNT(1) FROM  test.`UC_USER` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36'  ;	0.514
UUID	SELECT  SQL_NO_CACHE COUNT(1) FROM test.`UC_USER_PK_VARCHAR_1` t WHERE  t.`CREATE_DATE` > '2016-07-01 10:26:36'   ;	1.092

기본 키 유형

SQL 문

실행 시간(초)

(1) 퍼지 범위 쿼리 1000개 데이터의 경우 UUID보다 Self-increasing ID의 성능이 더 좋습니다

Self-increasing ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`MOBILE` LIKE '147%' LIMIT 1000;

1.784

UUID

SELECT SQL_NO_CACHE t.* FROM 테스트. `UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` LIKE '147%' LIMIT 1000;

3.196 td>

(2) 날짜 범위 20개의 데이터를 쿼리하면 자동으로 증분 ID는 UUID보다 약간 약합니다 td>

자동 증분 ID

SELECT SQL_NO_CACHE t.* FROM test.` UC_USER` t WHERE t.`CREATE_DATE` > '2016-08-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 20;

0.601

UUID

0.543

(3) 범위 쿼리 200개 데이터, 자동 증가 ID 성능은 UUID보다 우수

자동 증가 ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`CREATE_DATE` > 2016-07-01 10:26:36' ORDER BY t.`UPDATE_DATE ` DESC LIMIT 200;

2.314

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t. `CREATE_DATE` > '2016-07-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 200;

3.229

범위 쿼리 총 수량, 자동 증가 ID가 더 좋음 UUID

자동 증가 ID

SELECT SQL_NO_CACHE COUNT(1) FROM 테스트.`UC_USER` t WHERE t.`CREATE_DATE` > ' 2016-07-01 10:26:36' ;

0.514

UUID

SQL_NO_CACHE 개수 선택(1 ) FROM 테스트.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > '2016-07 -01 10:26:36' ;

1.092

PS: 캐시가 있는 경우 둘 사이의 실행 효율성에는 작은 차이가 없습니다.

2.4 쓰기 테스트, 자동 증가 ID 은 4회

기본 키 유형 업데이트 테스트.`UC_USER` t SET t.`MOBILE_TGC`='T2' WHERE t.`CREATE_DATE` > ' 2016-05-03 10:26:36' AND t.`CREATE_DATE` <'2016-05- 04 00:00:00' ;UUIDUPDATE 테스트.`UC_USER_PK_VARCHAR_1` t SET t.`MOBILE_TGC`='T2' WHERE t.`CREATE_DATE` > ; '2016-05-03 10:26:36' AND t.`CREATE_DATE` <'2016- 05-04 00:00:00' ;자동 증가 IDINSERT INTO 테스트.`UC_USER`( ID, `USER_NAME`, `USER_PWD`, `BIRTHDAY`, `NAME`, `USER_ICON`, `SEX`, `NICKNAME`, `STAT`, `USER_MALL`, `LAST_LOGIN_DATE`, ` LAST_LOGIN_IP`, `SRC_OPEN_USER_ID`, `EMAIL`, `MOBILE`, `IS_DEL`, `IS_EMAIL _CONFIRMED`, `IS_PHONE_CONFIRMED`, `CREATER`, `CREATE_DATE`, `UPDATE_DATE`, `PWD_INTENSITY`, `MOBILE_TGC`, `MAC `, `SOURCE`, `ACTIVATE`, `ACTIVATE_TYPE` ) SELECT NULL, `USER_NAME`,8 ), `USER_PWD`, `BIRTHDAY`, `NAME`, `USER_ICON`, `SEX`, `NICKNAME`, `STAT `, `USER_MALL`, `LAST_LOGIN_DATE`, `LAST_LOGIN_IP`, `SRC_OPEN_USER_ ID`, `EMAIL`, CONCAT('110',TRIM(`MOBILE`)), `IS_DEL`, `IS_EMAIL_CONFIRMED`, `IS_PHONE_CONFIRMED`, ` CREATER`, `CREATE_DATE`, `UPDATE_DATE`, `PWD_INTENSITY`, `MOBILE_TGC`, `MAC`, `SOURCE`, `ACTIVATE`, `ACTIVATE_TYPE` FROM `test`.`UC_USER_1` LIMIT 100;UUID

SQL 문	실행 시간(초)
		자동증가ID
1.419
5.639
0.105			INSERT INTO  test.`UC_USER_PK_VARCHAR_1`(     ID,   `USER_NAME`,   `USER_PWD`,   `BIRTHDAY`,   `NAME`,    `USER_ICON`,   `SEX`,   `NICKNAME`,   `STAT` ,    `USER_MALL`,    `LAST_LOGIN_DATE`,    `LAST_LOGIN_IP`,    `SRC_OPEN_USER_ID`,    `EMAIL`,   `MOBILE`,   `IS_DEL`,    `IS_EMAIL_CONFIRMED`,   `IS_PHONE_CONFIRMED`,   `CREATER`,   `CREATE_DATE`,   `UPDATE_DATE`,   ` PWD_INTENSITY`,   `MOBILE_TGC`,   `MAC`,    `SOURCE`,   `ACTIVATE`,   `ACTIVATE_TYPE` ) SELECT         UUID(),   CONCAT('110',`USER_NAME`,8),   `USER_PWD`,   `BIRTHDAY`,   ` NAME`,    `USER_ICON`,   `SEX`,   `NICKNAME`,   `STAT`,    `USER_MALL`,   `LAST_LOGIN_DATE`,   `LAST_LOGIN_IP`,   `SRC_OPEN_USER_ID`,   `EMAIL`, CONCAT('110',TRIM(`MOBILE` )),   `IS_DEL`,    `IS_EMAIL_CONFIRMED`,    `IS_PHONE_CONFIRMED`,    `CREATER`,   `CREATE_DATE`,   `UPDATE_DATE`,   `PWD_INTENSITY`,   `MOBILE_TGC`,   `MAC`,    `SOURCE`,   `ACTIVATE` ,   `ACTIVATE_TYPE` FROM `test`.`UC_USER_1`  100개 제한;	0.424

 

 

 

2.5、备份和恢复，自增ID性能优于UUID

主键类型	SQL语句	执行时间 (秒)
Mysqldump备份
自增ID	time mysqldump -utim -ptimgood -h192.168.121.63 test UC_USER_500> UC_USER_500.sql	28.59秒
UUID	time mysqldump -utim -ptimgood  -h192.168.121.63 test UC_USER_PK_VARCHAR_500> UC_USER_PK_VARCHAR_500.sql	31.08秒
MySQL恢复
自增ID	time mysql  -utim -ptimgood -h192.168.121.63  test < UC_USER_500.sql	7m36.601s
UUID	time mysql -utim -ptimgood -h192.168.121.63 test < UC_USER_PK_VARCHAR_500.sql	9m42.472s

<🎜>主键类型 <🎜><🎜 ><🎜><🎜>SQL语句<🎜><🎜><🎜><🎜>执行时间(秒)<🎜><🎜><🎜>< tr>

 <🎜>

Mysqldump备份<🎜><🎜><🎜><🎜><🎜>자체 ID<🎜><🎜><🎜><🎜>time mysqldump -utim -ptimgood  -h192.168.121.63 테스트 UC_USER_500> UC_USER_500.sql28.59秒

UUID시간 mysqldump -utim -ptimgood  -h192.168.121.63 테스트 UC_USER_PK_VARCHAR_500> UC_USER_PK_VARCHAR_500.sql31.08秒

 

MySQL恢复

자체IDtime mysql  -utim -ptimgood -h192.168.121.63  test < UC_USER_500.sql<🎜><🎜><🎜><🎜>7분36.601초<🎜><🎜><🎜><🎜><🎜>UUID<🎜><🎜><🎜><🎜>시간 mysql -utim -ptimgood -h192.168.121.63  테스트 < UC_USER_PK_VARCHAR_500.sql<🎜><🎜><🎜><🎜>9m42.472s<🎜><🎜><🎜><🎜><🎜> <🎜><🎜>< 🎜><🎜> <🎜><🎜><🎜><🎜> <🎜><🎜><🎜><🎜><🎜>

3, 500W요약

500W 레코드 테이블 테스트:

(1) 일반 단일 또는 약 20개 레코드 검색의 경우 uuid가 기본 키입니다. 효율성은 거의 같습니다.

(2) 그러나 범위 쿼리의 경우, 특히 수백 또는 수천 개의 레코드에 대해서는 자동 증가 ID의 효율성이 uuid보다 큽니다.

(3) 범위 쿼리에서 통계를 요약하면 자체 증가 ID의 효율성이 uuid보다 큽니다.

(4) 저장 측면에서 자체 증가 ID가 차지하는 저장 공간은 uuid의 1/2입니다.

(5 ) 백업 및 복구 측면에서 자동 증가 ID 기본 키는 UUID보다 약간 더 좋습니다.

4、1000W데이터 테스트

4.1 입력1000W데이터기록, 저장공간 참고

# 自增id为主键的表

mysql> use test;

Database changed

mysql> select count(1) from UC_USER_1;

+----------+

| count(1) |

+----------+

| 10698102 |

+----------+

1 row in set (27.42 sec)

 

# uuid为主键的表

mysql> select count(1) from  UC_USER_PK_VARCHAR_1;

+----------+

| count(1) |

+----------+

| 10698102 |

+----------+

1 row in set (0.00 sec)

 

mysql>

#

자체 증분

id 기본 키로 테이블

主键类型	数据文件大小	占据容量
自增ID	-rw-rw---- 1 mysql mysql 4.2G Aug 20  23:08 UC_USER_1.ibd	4.2 G
UUID	-rw-rw---- 1 mysql mysql 8.8G Aug 20  18:20 UC_USER_PK_VARCHAR_1.ibd	8.8 G

mysql> use test;데이터베이스 변경됨mysql> UC_USER_1에서 count(1) 선택;+ - ----------+| 개수(1) |+----------+| |+----------+1행 세트(27.42초) # uuid 기본 키가 있는 테이블mysql> UC_USER_PK_VARCHAR_1에서 count(1) 선택;+---------+ | 개수(1) |+----------+| 10698102 |+------- -- -+세트의 1개 행(0.00초) mysql>

점유된 공간 용량으로 볼 때 자동 증가 ID는 UUID보다 절반 정도 작습니다. 자동 증가 ID

기본 키 유형	데이터 파일 크기	점유 용량
-rw-rw---- 1 mysql mysql 4.2G 8월 20일 23:08 UC_USER_1 .ibd	4.2G
UUID	-rw-rw---- 1 mysql mysql 8.8G 8월 20일 18:20 UC_USER_PK_VARCHAR_1.ibd td>	8.8G

4.2 단일 데이터는 인덱스로 조회, 자동 증분id과 uuid 사이의 효율성 비율은 다음과 같습니다. (2~3):1

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_1` t WHERE t.`MOBILE` ='14782121512';

날짜 기준 쿼리

主键类型	SQL语句	执行时间 (秒)
单条记录查询
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_1` t WHERE t.`MOBILE` ='14782121512';	0.069
UUID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` ='14782121512';	0.274
小范围查询
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_1` t WHERE t.`MOBILE` IN( '14782121512','13761460105');	0.050
UUID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE`  IN('14782121512','13761460105');	0.151
根据日期查询
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_1` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:36' ;	0.269
UUID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:43' ;	0.810

기본 키 유형

SQL 문

실행 시간(초) )

단일 레코드 쿼리

자동 증가 ID

0.069

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` ='14782121512';

0.274

작은 범위 쿼리

자체 증가 ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_1` t WHERE t.`MOBILE` IN( '14782121512',' 13761460105');

0.050

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` IN('14782121512' ,'13761460105');

0.151

자동 증가 ID

SELECT SQL_NO_CACHE t .* FROM 테스트.`UC_USER_1` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:36' ;

0.269

UUID

SELECT SQL_NO_CACHE t.* FROM test .`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE`='2013-11-24 10:26:43' ;

0.810

4.3 Scopelike쿼리, 자동 증가 ID는 UUID, ratio(1.5~2)보다 성능이 뛰어납니다.1

tr>자동 증가 ID UUID2.302

主键类型	SQL语句	执行时间 (秒)
（1）模糊范围查询1000条数据，自增ID性能要好于UUID
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER` t WHERE t.`MOBILE` LIKE '147%' LIMIT 1000;	2.398
UUID	SELECT  SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` LIKE  '147%' LIMIT 1000;	5.872
（2）日期范围查询20条数据，自增ID稍微弱于UUID
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_1` t WHERE t.`CREATE_DATE` > '2016-08-01 10:26:36' ORDER BY  t.`UPDATE_DATE` DESC LIMIT 20;	0.765
UUID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > '2016-08-01  10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 20;	1.090
（3）范围查询200条数据，自增ID性能要好于UUID
自增ID	SELECT SQL_NO_CACHE t.* FROM  test.`UC_USER_1` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36' ORDER BY  t.`UPDATE_DATE` DESC LIMIT 200;	1.569
UUID	SELECT  SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE`  > '2016-07-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 200;	2.597
范围查询总数量，自增ID要好于UUID
自增ID	SELECT SQL_NO_CACHE COUNT(1) FROM  test.`UC_USER_1` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36'  ;	1.129
UUID	SELECT  SQL_NO_CACHE COUNT(1) FROM test.`UC_USER_PK_VARCHAR_1` t WHERE  t.`CREATE_DATE` > '2016-07-01 10:26:36'   ;	2.302

기본 키 유형

SQL 문

실행 시간(초)

(1) 퍼지 범위 쿼리 1000개 데이터, 자동 증가 ID 성능이 UUID보다 우수함 td>

자동 증가 ID

SELECT SQL_NO_CACHE t.* FROM 테스트. `UC_USER` t WHERE t .`MOBILE` LIKE '147%' LIMIT 1000;

2.398

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` LIKE '147%' 제한 1000 ;

5.872

(2) 해당 날짜 범위의 데이터를 20개 쿼리하고, 자동 증가 ID가 UUID보다 약간 약함

자동 증가 ID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_1` t WHERE t.`CREATE_DATE` > '2016-08-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 20;

0.765

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > '2016-08-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 20;

1.090

(3) 범위 쿼리 200개 데이터, 자동 증가 ID 성능이 UUID보다 우수함

자동 증가 ID td>

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_1` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36' ORDER BY t.` 업데이트_날짜` DESC 제한 200;

1.569

UUID

SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > ' ORDER BY t.`UPDATE_DATE` DESC LIMIT 200;

2.597

범위 쿼리 총 수량, 자동 증가 ID가 UUID보다 좋음

SELECT SQL_NO_CACHE COUNT(1) FROM test.`UC_USER_1` t WHERE t.`CREATE_DATE ` > '2016-07-01 10:26:36' ; td>

1.129

SELECT SQL_NO_CACHE COUNT(1) FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` > '2016-07-01 10:26:36' ;

4.4 쓰기 테스트, 자동 증가 ID UUID보다 효율적이고 비율은 (3~10): 1

기본 키 유형	SQL 문	실행 시간(초)
하루의 기록 수정
ID증가	업데이트 테스트.`UC_USER_1` t SET t.`MOBILE_TGC`='T2' WHERE t.`CREATE_DATE` > '2016-05-03 10:26:36' AND t.`CREATE_DATE` < '2016-05-04 00:00:00' ;	2.685
UUID	UPDATE 테스트.`UC_USER_PK_VARCHAR_1` t SET t.`MOBILE_TGC`='T2' WHERE t.`CREATE_DATE` > '2016-05-03 10:26:36' AND t.`CREATE_DATE` <'2016- 05-04 00:00:00' ;	26.521
데이터 입력
자동 증가 ID	INSERT INTO 테스트`UC_USER_1`( ID, `USER_NAME `, `USER_PWD`, `BIRTHDAY`, `NAME`, `USER_ICON`, `SEX`, `NICKNAME`, `STAT`, `USER_MALL`, `LAST_LOGIN_DATE`, `LAST_LOGIN_IP`, `SRC_OPEN_USER_ID`, `EMAIL`, `MO BILE`, `IS_DEL`, `IS_EMAIL_CONFIRMED`, `IS_PHONE_CONFIRMED`, `CREATER`, `CREATE_DATE`, `UPDATE_DATE`, `PWD_INTENSITY`, `MOBILE_TGC`, `MAC`, `SOURCE`, `ACTIVATE`, ` ACTIVATE _TYPE` ) SELECT NULL, CONCAT ; `Last_login_ip`, `SRC_OPEN_USER_ID`, `EMAIL`, CONCAT('110',TRIM(`MOBILE`)), `IS_DEL`, `IS_EMAIL_CONFIRMED`, `IS_PHONE_CONFIRMED`, `CREATER` , `CREATE_DATE`, `UPDATE_DATE`, `PWD_INTENSITY`, `MOBILE_TGC`, `MAC`, `SOURCE`, `ACTIVATE`, `ACTIVATE_TYPE` FROM `test`.`UC_USER_1` LIMIT 100;	0.534
UUID	INSERT INTO 테스트.`UC_USER_PK_VARCHAR_1`(    ID,    `USER_NAME`,   `USER_PWD`,   `BIRTHDAY`,   `NAME`,    `USER_ICON`,   `SEX`,   `NICKNAME`,   `STAT` ,    `USER_MALL`,    `LAST_LOGIN_DATE`,    `LAST_LOGIN_IP`,    `SRC_OPEN_USER_ID`,   `EMAIL`,   `MOBILE`,    `IS_DEL`,   `IS_EMAIL_CONFIRMED`,   `IS_PHONE_CONFIRMED`,   `CREATER`,  CREATE_DATE`,   `UPDATE_DATE`,   ` PWD_INTENSITY`,   `MOBILE_TGC`,   `MAC`,    `SOURCE`,   `ACTIVATE`,   `ACTIVATE_TYPE` ) SELECT         UUID(),   CONCAT('110',`USER_NAME`,8),   `USER_PWD`,   `BIRTHDAY`,   ` NAME`,    `USER_ICON`,   `SEX`,   `NICKNAME`,   `STAT`,    `USER_MALL`,    `LAST_LOGIN_DATE`,    `LAST_LOGIN_IP`,    `SRC_OPEN_USER_ID`,   `EMAIL`,  CONCAT('110',TRIM(`MOBILE` )),    `IS_DEL`,    `IS_EMAIL_CONFIRMED`,    `IS_PHONE_CONFIRMED`,    `CREATER`,   `CREATE_DATE`,   `UPDATE_DATE`,   `PWD_INTENSITY`,   `MOBILE_TGC`,   `MAC`,    `SOURCE`,   `ACTIV ATE`,   `ACTIVATE_TYPE` FROM `test`.`UC_USER_1`  한도 100;	1.716

 

 

 

4.5、备份和恢复，自增ID性能优于UUID

主键类型	SQL语句	执行时间 (秒)
Mysqldump备份
自增ID	time mysqldump -utim -ptimgood -h192.168.121.63 test UC_USER_1> UC_USER_1.sql	0m50.548s
UUID	time mysqldump -utim -ptimgood  -h192.168.121.63 test UC_USER_PK_VARCHAR_1> UC_USER_PK_VARCHAR_1.sql	0m58.590s
MySQL恢复
自增ID	time mysql -utim -ptimgood  -h192.168.121.63 test < UC_USER_1.sql	17m30.822s
UUID	time mysql -utim -ptimgood -h192.168.121.63 test < UC_USER_PK_VARCHAR_1.sql	23m6.360s

<🎜>主键类型 <🎜><🎜 ><🎜><🎜>SQL语句<🎜><🎜><🎜><🎜>执行时间(秒)<🎜><🎜><🎜>< tr>

 <🎜>

Mysqldump备份<🎜><🎜><🎜><🎜><🎜>자체 ID<🎜><🎜><🎜><🎜>time mysqldump -utim -ptimgood -h192.168.121.63  UC_USER_1 테스트> UC_USER_1.sql0m50.548s

UUID시간 mysqldump -utim -ptimgood  -h192.168.121.63 test UC_USER_PK_VARCHAR_1> UC_USER_PK_VARCHAR_1.sql0m58.590s

 

MySQL 지원

自增IDtime mysql -utim -ptimgood  -h192.168.121.63 test < UC_USER_1.sql<🎜><🎜><🎜><🎜>17분30.822초<🎜><🎜><🎜><🎜><🎜>UUID<🎜><🎜><🎜><🎜>시간 mysql -utim -ptimgood  -h192.168.121.63 test < UC_USER_PK_VARCHAR_1.sql<🎜><🎜><🎜><🎜>23분6.360초<🎜><🎜><🎜><🎜><🎜> <🎜><🎜>< 🎜><🎜> <🎜><🎜><🎜><🎜> <🎜><🎜><🎜><🎜><🎜>

5, 1000W요약

1000W 레코드 테이블 테스트:

(1) 일반적인 단일 또는 약 20개 레코드 검색의 경우 자동 증가 기본 키의 효율성은 2~3배입니다. uuid 기본 키

(2) 그러나 범위 쿼리의 경우, 특히 수백 또는 수천 개의 레코드에 대해서는 자동 증가 ID의 효율성이 uuid보다 큽니다.

(3) 범위 쿼리에 대한 통계 요약을 수행할 때 자동 증가 ID 기본 키의 효율성은 uuid 기본 키의 1.5~2배입니다.

(4) 저장 측면에서 보면, 자동 증가 ID는 uuid의 1/2입니다.

( 5) 쓰기 측면에서 자동 증가 ID 기본 키의 효율성은 UUID 기본 키의 3~10배입니다. 이는 특히 작은 범위 내에서 데이터를 업데이트할 때 분명합니다.

(6) 백업 및 복구 측면에서는 자체 증가 ID 기본 키가 UUID보다 약간 더 좋습니다.

6, MySQL분산 아키텍처 절충

분산 아키텍처는 테이블의 기본 키의 고유성이 여러 인스턴스에서 유지되어야 함을 의미합니다. 현재 일반 단일 테이블 자체 증가 ID 기본 키는 적합하지 않습니다. 여러 mysql 인스턴스에서 기본 키의 전역 고유성 문제가 발생하기 때문입니다.

6.1, 자동증가 ID 기본 키 + 단계 크기, 중간 규모 분산 시나리오에 적합

각 클러스터 노드 그룹의 마스터에서, (auto_increment_increment)를 설정하고, 각 클러스터의 현재 시작점을 1씩 엇갈리게 하고, 미래에 기본적으로 달성할 수 없는 분할 클러스터 수보다 더 큰 단계 크기를 선택하여 ID를 상대적으로 분할하는 효과를 얻습니다. 글로벌 고유 효과를 만나보세요.

장점은 간단한 구현, 간단한 사후 유지 관리, 애플리케이션 투명성입니다.

단점: 향후 비즈니스 개발을 위해 충분한 단계 크기를 계산해야 하기 때문에 첫 번째 설정이 상대적으로 복잡합니다. ;

계획:

예를 들어 총 N개의 노드 그룹이 계획된 경우 i- my.cnf의 구성은 다음과 같습니다.

auto_increment_offset i

auto_increment_increment N

48개의 노드 그룹이 계획된 경우 N은 48입니다. 이제 8번째 노드 그룹을 구성합니다. i는 8입니다. 8번째 노드 그룹의 my.cnf 구성은

auto_increment_offset 8

auto_increment_increment 48

입니다.

6.2, UUID, 소규모 분산 환경에 적합

InnoDB와 같은 클러스터형 기본 키 유형 엔진의 경우 UUID의 무질서로 인해 데이터가 기본 키에 따라 정렬되며 InnoDB는 엄청난 IO 압력을 발생시키고 인덱스와 데이터가 함께 저장되기 때문에 , 문자열은 기본 키로 인해 저장 공간이 두 배로 늘어납니다.

innodb는 저장 및 검색 중에 기본 키를 물리적으로 정렬합니다. 이는 나중에 삽입되는 기본 키의 위치가 항상 끝에 있기 때문에 auto_increment_int에 좋은 소식입니다. 하지만 uuid의 경우 이는 나쁜 소식입니다. 왜냐하면 uuid는 지저분하고 매번 삽입되는 기본 키의 위치가 불확실하기 때문입니다. 기본 키를 물리적으로 정렬할 때 필연적으로 발생할 수 있는 문제가 있습니다. 많은 수의 IO 작업은 효율성에 영향을 미칩니다. 데이터 양이 계속 증가하면, 특히 데이터 양이 수천만 개의 레코드를 초과하는 경우 읽기 및 쓰기 성능이 급격히 떨어집니다.

장점: 구성이 비교적 간단하고 기본 키의 고유성이 필요하지 않습니다.

단점: 저장 공간을 두 배로 차지합니다(클라우드 저장소 한 개에 대해 2배 더 많은 비용 발생). 나중에 읽기 쓰기 성능이 급격히 떨어집니다.

6.3, Snowflake 알고리즘은 전역 자체 생성 made 빅데이터 환경의 분산 시나리오에 적합한 ID 추가

트위터에서 발표한 오픈소스 분산 ID 알고리즘 눈송이(Java 버전)

IdWorker.java：

package com.demo.elk;

org.slf4j.Logger 가져오기

org.slf4j.LoggerFactory 가져오기;

     보호된 정적 최종 로거 LOG =  LoggerFactory.getLogger(IdWorker.class);

    

     private long WorkerId;

     private long datacenterId;

private long 시퀀스 = 0L;

 

     private long twepoch = 1288834974657L;

 

     private long WorkerIdBits = 5L;

     priv 오래 먹었다 datacenterIdBits = 5L;

     private long maxWorkerId = -1L ^ (-1L <

     private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);

<<> 개인 긴 시퀀스 비트 = 12L;

개인 Long WorkerIdshift = SequenceBits;

개인 Long DatacenterIdShift = SequenceBits + WorkerIdbits; <🎜

<🎜 🎜> private long timestampLeftShift = sequenceBits + WorkerIdBits +  datacenterIdBits;

     private long sequenceMask = -1L ^ (-1L << 시퀀스Bits);

 

     private long lastTimestamp = - 1L;

 

     public IdWorker(긴 작업자 ID, 긴 데이터 센터 ID) {

         // 작업자 ID

에 대한 온전성 검사         if (workerId > maxWorkerId || 작업자 ID < 0) {

            새로운  IllegalArgumentException(String.format("작업자 ID는  %d보다 크거나 0보다 작을 수 없습니다.", maxWorkerId));

         }

         if (datacenterId > maxDatacenterId || datacenterId < 0) {

             throw new  IllegalArgumentException(String.format("datacenter Id can't be less than %d or less than 0", maxDatacenterId));

         }

         this.workerId = WorkerId;

         this.datacenterId = datacenterId;

         LOG.info(String.format("작업자 시작 시간. 앰프 왼쪽 시프트 %d,  데이터센터 ID 비트 %d, 작업자 ID 비트 %d, 시퀀스 비트 %d, 작업자 ID  %d", timestampLeftShift, datacenterIdBits, WorkerIdBits, SequenceBits,  workerId));

     }

 

     공개 동기화된 긴 nextId() {

         long timestamp = timeGen();

 

         if (timestamp < lastTimestamp) {

             LOG.error(String.format("시계가 뒤로 이동 중입니다.  %d까지 요청을 거부합니다.",  lastTimestamp));

            throw new  RuntimeException(String.format("시계가 뒤로 이동했습니다.  %d  밀리초 동안 ID 생성 거부", lastTimestamp - timestamp));

         }

 

        if (lastTimestamp == timestamp) {

            시퀀스 = (시퀀스 + 1) &  sequenceMask;

            if (시퀀스 == 0) {

               timestamp =  tilNextMillis(lastTimestamp);

           }

         } else {

            시퀀스 = 0L;

         }

 

        lastTimestamp = 타임스탬프;

 

         반환(( timestamp - twepoch) << timestampLeftShift) |   (datacenterId << datacenterIdShift) | (workerId

    }

 

protected long tilNextMillis(long lastTimestamp) {

         long timestamp = timeGen();

         while (timestamp <= lastTimestamp) {

            timestamp = timeGen();

         }

         return timestamp;

     }

 

     보호된 오랜 시간Gen() {

         return  System.currentTimeMillis();

     }

}

 

 

 

测试生成ID 测试类，IdWorkerTest.java：

package com.demo.elk;

import java.util.HashSet;

import java.util.Set;

public class IdWorkerTest {

static class IdWorkThread implements Runnable {

private Set set;

         private IdWorker idWorker;

 

         public IdWorkThread(Set set, IdWorker idWorker) {

            this.set = set;

            this.idWorker = idWorker;

         }

 

         public void run() {

            while (true) {

                 long id =  idWorker.nextId();

                 System.out.println("             real id:" + id);

                if (!set.add(id)) {

                     System.out.println("duplicate:" + id);

                }

            }

         }

     }

 

     public static void main(String[] args) {

         Set set = new HashSet();

         final IdWorker idWorker1 = new IdWorker(0, 0);

         final IdWorker idWorker2 = new IdWorker(1, 0);

         Thread t1 = new Thread(new IdWorkThread(set, idWorker1));

        Thread t2 = new Thread(new  IdWorkThread(set, idWorker2));

         t1.setDaemon(true);

         t2.setDaemon(true);

         t1.start();

         t2.start();

         try {

            Thread.sleep(30000);

         } catch (InterruptedException e) {

             e.printStackTrace();

         }

     }

}

package com.demo.elk; java.util.HashSet 가져오기;java.util 가져오기. Set; public class IdWorkerTest {               정적 클래스 IdWorkThread는 Runnable을 구현합니다. {         private Set set;         private IdWorker idWorker;          public IdWorkThread(Set set, IdWorker idWorker) {           this.set = 설정;           this.idWorker = idWorker;         }          public void run() {            동안(tru 전자) {                 긴 ID =  idWorker.nextId();                System.out.println("            실제 ID:" + id);                if (!set.add(id)) {                    System.out.println("duplicate:" + id);              }           }         }     }      public static void main(String[] args) {         Set set = new HashSet();         final IdWorker idWorker1 = new IdWorker(0, 0);         final IdWorker idWorker2 = new IdWorker(1, 0);         스레드 t1 = new Thread(new IdWorkThread(set, idWorker1));        스레드 t2 = new Thread(new  IdWorkThread(set, idWorker2));         t1.setDaemon(true) ;         t2.setDaemon(true);         t1.start();         t2.start();         시도해 보세요 {            Thread.sleep(30000);         } catch (InterruptedException e) {             e.printTrace();         }      }}

7, 요약

(1) 단일 인스턴스 또는 단일 노드 그룹:

500W 및 1000W 독립형 테이블 테스트 후 자동 증가 ID가 UUID보다 낫습니다. 증분 ID 기본 키의 성능은 UUID보다 높으며 디스크 저장 비용은 UUID의 절반입니다. 따라서 단일 인스턴스 또는 단일 노드 그룹에서 자동 증가 ID를 기본 기본 키로 사용합니다.

(2) 분산 아키텍처 시나리오:

20개 노드 그룹의 소규모 분산 시나리오에서는 UUID 기본 키를 다중 꽃 저장 비용으로 빠르게 배포할 수 있으며

20~200개의 노드 그룹이 있는 중간 규모 분산 시나리오의 경우 자체 증가 ID + 단계 크기의 더 빠른 솔루션을 사용할 수 있습니다.

노드 그룹이 200개 이상인 빅데이터의 분산 시나리오는 Twitter Snowflake 알고리즘에 의해 생성된 전역 자동 증가 ID를 기본 키로 학습할 수 있습니다.

위는 MySQL에서 Auto-incrementing ID 기본키와 UUID를 기본키로 사용할 때의 장단점을 자세하게 비교하는 과정이다. 수천만 개의 테이블 레코드까지). 더 많은 관련 내용을 보려면 PHP 중국어 웹사이트(www.php.cn)를 주목하세요!

관련 라벨：

MySQL ，UUID ，优劣比较

원천：php.cn

이전 기사：mySql 연구 노트: SQL Server를 작성하는 것보다 쉽습니다. 다음 기사：자동 증가 ID 기본 키와 UUID를 기본 키로 사용하는 MySQL의 장단점을 비교하는 세부 과정(500W 단일 테이블)

본 웹사이트의 성명

본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

저자별 최신 기사

• 자신만의 PHP 프레임워크를 처음부터 구축하는 방법에 대한 비디오 자료
  2023-03-15 16:54:01
• PHPMailer가 QQ 메일함을 사용하여 이메일 전송 기능을 완성하는 방법에 대한 분석 예
  2023-03-15 12:26:02
• PHP의 IMAP에서 이메일을 받는 방법 소개
  2023-03-14 18:58:01
• PHP에서 배열 중복 제거를 신속하게 구현하는 방법의 예
  2023-03-14 11:30:01
• HTML에서 태그의 모든 속성 사용 요약
  1970-01-01 08:00:00
• PHP에 대한 기본 지식 요약(초보자가 시작하는 데 필요함)
  2023-03-16 15:20:01
• JavaScript에서 typeof 사용 소개
  1970-01-01 08:00:00
• JavaScript의 verify() 메소드 사용 소개
  1970-01-01 08:00:00
• HTML5 자리표시자 속성에 대한 자세한 소개
  1970-01-01 08:00:00
• ReactJS의 양식에서 단일 선택, 다중 선택 및 역선택을 구현하는 방법
  1970-01-01 08:00:00

최신 이슈

function_exists()는 사용자 정의 함수를 결정할 수 없습니다. 기능 테스트() {                                                                                ...

에서 2024-04-29 11:01:01

0

2

2012

Chrome 모바일 버전을 표시하는 방법 안녕하세요 선생님, Chrome을 모바일 버전으로 어떻게 변경하나요?

에서 2024-04-23 00:22:19

0

10

2171

자식 창이 부모 창을 작동하지만 출력이 응답하지 않습니다. 처음 두 문장은 실행 가능하지만 마지막 문장은 구현할 수 없습니다.

에서 2024-04-19 15:37:47

0

1

1835

상위 창에 출력이 없습니다. document.onclick = function(){ window.opener.document.write('나는 자식 창의 출력입니다.');

에서 2024-04-18 23:52:34

0

1

1728

CSS 마인드맵 코스웨어는 어디에 있나요? 코스웨어

에서 2024-04-16 10:10:18

0

0

1747

관련 주제

더>

• mysql은 데이터 테이블 이름을 수정합니다.
• MySQL은 저장 프로시저를 생성합니다.
• 몽고디비와 mysql의 차이점
• mysql 비밀번호를 잊었는지 확인하는 방법
• mysql은 데이터베이스 생성
• mysql 기본 트랜잭션 격리 수준
• sqlserver와 mysql의 차이점
• mysql비밀번호를 잊어버렸습니다

인기 추천

• mysql을 깨끗하게 제거하는 방법은 무엇입니까?
• SQL은 무엇을 의미합니까?
• SQL 추가, 삭제, 수정, 쿼리 문이란 무엇입니까?
• mysql 버전 확인하는 방법
• 데이터베이스 SQL Server를 완전히 제거하는 방법은 무엇입니까?

인기 튜토리얼

더>

관련 튜토리얼

인기 추천

최신 강좌

• 
  최신 ThinkPHP 5.1 세계 최초 비디오 튜토리얼(PHP 전문가 온라인 교육 과정이 되기까지 60일)

  1420865
• 
  PHP 입문 튜토리얼 1: 일주일 안에 PHP 배우기

  4264355
• 
  JAVA 초보자용 비디오 튜토리얼

  2513322
• 
  Little Turtle의 Python 학습에 대한 제로 기반 소개 비디오 튜토리얼

  505943
• 
  PHP 제로 기반 입문 튜토리얼

  861084

• 
  최신 ThinkPHP 5.1 세계 최초 비디오 튜토리얼(PHP 전문가 온라인 교육 과정이 되기까지 60일)

  1420865 학습 시간
• 
  JAVA 초보자용 비디오 튜토리얼

  2513322 학습 시간
• 
  Little Turtle의 Python 학습에 대한 제로 기반 소개 비디오 튜토리얼

  505943 학습 시간
• 
  웹 프론트 엔드 개발에 대한 빠른 소개

  215592 학습 시간
• 
  PS 비디오 튜토리얼을 처음부터 마스터하세요

  885590 학습 시간

• 
  [웹 프런트엔드] Node.js 빠른 시작

  7156 학습 시간
• 
  해외 웹 개발 풀스택 강좌 총집합

  5557 학습 시간
• 
  Go 언어 실습 GraphQL

  4671 학습 시간
• 
  550W 팬 마스터가 JavaScript를 처음부터 차근차근 학습합니다

  670 학습 시간
• 
  기초 지식이 전혀 없는 초보자도 6시간 만에 시작할 수 있는 파이썬 마스터 모쉬

  23606 학습 시간

최신 다운로드

더>

웹 효과

웹사이트 소스 코드

웹사이트 자료

프론트엔드 템플릿

• [양식 버튼] jQuery 기업 메시지 양식 연락처 코드
• [플레이어 특수 효과] HTML5 MP3 뮤직 박스 재생 효과
• [메뉴 탐색] HTML5 멋진 입자 애니메이션 탐색 메뉴 특수 효과
• [양식 버튼] jQuery 시각적 양식 드래그 앤 드롭 편집 코드
• [플레이어 특수 효과] VUE.JS 모방 Kugou 음악 플레이어 코드
• [HTML5 특수 효과] 클래식 HTML5 푸시 박스 게임
• [그림 특수 효과] 이미지 효과를 추가하거나 줄이기 위해 jQuery 스크롤
• [사진 앨범 효과] CSS3 개인 앨범 커버 호버 확대/축소 효과

• [프런트엔드 템플릿] 가정 장식 청소 및 수리 서비스 회사 웹사이트 템플릿
• [프런트엔드 템플릿] 신선한 색상의 개인 이력서 가이드 페이지 템플릿
• [프런트엔드 템플릿] 디자이너 크리에이티브 작업 이력서 웹 템플릿
• [프런트엔드 템플릿] 현대 엔지니어링 건설 회사 웹사이트 템플릿
• [프런트엔드 템플릿] 교육 서비스 기관을 위한 반응형 HTML5 템플릿
• [프런트엔드 템플릿] 온라인 전자책 쇼핑몰 웹사이트 템플릿
• [프런트엔드 템플릿] IT 기술로 인터넷 회사 웹 사이트 템플릿을 해결합니다.
• [프런트엔드 템플릿] 보라색 스타일 외환 거래 서비스 웹 사이트 템플릿

• [PNG 소재] 귀여운 여름 요소 벡터 자료(EPS+PNG)
• [PNG 소재] 4개의 빨간색 2023 졸업 배지 벡터 자료(AI+EPS+PNG)
• [배너 그림] 노래하는 새와 꽃 디자인 봄 배너 벡터 자료로 가득 찬 카트(AI+EPS)
• [PNG 소재] 황금 졸업 모자 벡터 자료(EPS+PNG)
• [PNG 소재] 흑백 스타일 산 아이콘 벡터 자료(EPS+PNG)
• [PNG 소재] 다양한 색상의 망토와 포즈를 갖춘 슈퍼히어로 실루엣 벡터 자료(EPS+PNG)
• [배너 그림] 플랫 스타일 식목일 배너 벡터 자료(AI+EPS)
• [PNG 소재] 9개의 만화 스타일의 폭발적인 채팅 거품 벡터 자료(EPS+PNG)

• [프런트엔드 템플릿] 가정 장식 청소 및 수리 서비스 회사 웹사이트 템플릿
• [프런트엔드 템플릿] 신선한 색상의 개인 이력서 가이드 페이지 템플릿
• [프런트엔드 템플릿] 디자이너 크리에이티브 작업 이력서 웹 템플릿
• [프런트엔드 템플릿] 현대 엔지니어링 건설 회사 웹사이트 템플릿
• [프런트엔드 템플릿] 교육 서비스 기관을 위한 반응형 HTML5 템플릿
• [프런트엔드 템플릿] 온라인 전자책 쇼핑몰 웹사이트 템플릿
• [프런트엔드 템플릿] IT 기술로 인터넷 회사 웹 사이트 템플릿을 해결합니다.
• [프런트엔드 템플릿] 보라색 스타일 외환 거래 서비스 웹 사이트 템플릿

공공복지 온라인 PHP 교육，PHP 학습자의 빠른 성장을 도와주세요！

회사 소개 부인 성명 Sitemap

© php.cn All rights reserved