Gemeinschaft Lernen Tools-Bibliothek Freizeit
suchen
Deutsch
Heim > Datenbank > MySQL-Tutorial > Hauptteil

Detaillierter Prozess zum Vergleich der Vor- und Nachteile der Verwendung des automatisch inkrementierenden ID-Primärschlüssels und der UUID als Primärschlüssel in MySQL (Testen von einer Million bis zehn Millionen Tabellendatensätzen)

黄舟
Freigeben： 2017-02-16 11:35:54
Original
1811 Leute haben es durchsucht

Grund für den Test

Ein Entwicklungskollege hat ein Framework erstellt, in dem der Primärschlüssel uuid ist. Ich schlug ihm vor, automatisch inkrementierende Primärschlüssel zu verwenden. Er sagte, dass dies nicht unbedingt der Fall sei Ich sagte, dass die Indexfunktion von innodb zur automatischen Inkrementierung von IDs am effizientesten ist. Um ihn anhand tatsächlicher Fälle zu überzeugen, habe ich mich auf einen detaillierten Test vorbereitet.

Als Internetunternehmen muss es eine Benutzertabelle geben, und die Benutzertabelle UC_USER hat im Grunde Millionen Daher wird der Test auf Basis der auf dieser Tabelle basierenden Quasi-Testdaten durchgeführt.

Der Testprozess ist derzeit ein vielschichtiger und häufig verwendeter SQL-Test, an den ich natürlich denke Möglicherweise ist es nicht perfekt. Jeder kann gerne eine Nachricht hinterlassen, um einen umfassenderen Testplan oder eine Test-SQL-Anweisung vorzuschlagen.

1. Tabellen und Daten vorbereitenUC_USER, Auto-Inkrement-ID als Primärschlüssel, Tabellenstruktur ähnelt der folgenden:

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-Tabelle, String-ID als Primärschlüssel, unter Verwendung von uuid

tbody>

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) ZEICHENSATZ utf8mb4 NICHT NULL STANDARD '0' KOMMENTAR 'Primärschlüssel', „USER_NAME“ varchar(100) DEFAULT NULL COMMENT „Benutzername“,
„USER_PWD“ varchar(200) DEFAULT NULL COMMENT „Passwort“,
„BIRTHDAY“ datetime DEFAULT NULL COMMENT „Geburtstag“, `NAME` varchar(200) DEFAULT NULL COMMENT 'Name',
`USER_ICON` varchar(500) DEFAULT NULL COMMENT 'Avatar picture',
`SEX` char(1) DEFAULT NULL KOMMENTAR 'Geschlecht, 1: Männlich, 2: Weiblich, 3: Vertraulich',
`NICKNAME` varchar(200) DEFAULT NULL COMMENT 'Spitzname',
`STAT` varchar(10) DEFAULT NULL COMMENT ' Benutzerstatus, 01: normal, 02: eingefroren',
`USER_MALL` bigint(20) DEFAULT NULL COMMENT 'Current MALL',
`LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT 'Letzte Anmeldezeit',
/> `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT 'Letzte Login-IP',
`SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT 'Quelle der gemeinsamen Anmeldung',
`EMAIL` varchar( 200) DEFAULT NULL COMMENT „Mailbox“,
„MOBILE“ varchar(50) DEFAULT NULL COMMENT „Mobiltelefon“,
„IS_DEL“ char(1) DEFAULT „0“ COMMENT „Ob gelöscht werden soll“,
`IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT 'Ob eine E-Mail-Adresse gebunden werden soll',
`IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT 'Ob ein Mobiltelefon gebunden werden soll',
`CREATER` bigint (20) DEFAULT NULL COMMENT 'Ersteller',
`CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT 'Registrierungszeit',
`UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT 'Änderungsdatum',
`PWD_INTENSITY` char(1) DEFAULT NULL COMMENT 'Passwortstärke',
`MOBILE_TGC` char(64) DEFAULT NULL COMMENT 'Mobile phone login ID',
`MAC` char(64 ) STANDARD NULL KOMMENTAR 'MAC-Adresse' ,
`SOURCE` char(1) STANDARD '0' KOMMENTAR '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:Managementsystem, 0:Unbekannt ',
`ACTIVATE `char(1) DEFAULT '1' COMMENT 'Aktivierung, 1: aktiviert, 0: nicht aktiviert',
`ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT 'Aktivierungstyp , 0: automatisch, 1: manuell ',
PRIMARY KEY (`ID`),
UNIQUE KEY `USER_NAME` (`USER_NAME`),
KEY `MOBILE` (`MOBILE`) ,
SCHLÜSSEL `IDX_MOBILE_TGC ` (`MOBILE_TGC`,`ID`),
SCHLÜSSEL `IDX_EMAIL` (`EMAIL`,`ID`),
SCHLÜSSEL `IDX_CREATE_DATE` (`CREATE_DATE`, `ID`),
KEY `IDX_UPDATE_DATE` (`UPDATE_DATE`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='User table';

2. 500WDatentest

2.1 500W Daten eingeben, automatische Inkrementierung ID die Hälfte sparen den Speicherplatz

Bestimmen Sie das Datenvolumen der beiden Tabellen

# 自增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)

# Tabelle mit Auto-Inkrement-ID als Primärschlüssel

mysql> select count(1) from UC_USER;

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

主键类型

数据文件大小

占据容量

自增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

|. count( 1) |

+---------+

| 5720112 |

+------- ---+1 Zeile im Satz (0,00 Sek.) mysql> # Tabelle mit UUID als primär keymysql> select count(1) from UC_USER_PK_VARCHAR_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
+----------+|. count(1) | +--- -------+| 5720112 |+----------+1 Zeile im Satz (1,91 Sek.)
Gemessen an der belegten Speicherplatzkapazität ist die Auto-Inkrement-ID etwa halb kleiner als UUID.
Primärschlüsseltyp Datendateigröße Belegte Kapazität strong>
Selbstinkrementierende ID -rw -rw---- 1 mysql mysql 2.5G 11. August 18:29 UC_USER.ibd 2.5 G
UUID -rw-rw---- 1 mysql mysql 5.4G 15. Aug. 15: 11 UC_USER_PK_VARCHAR_1.ibd 5,4 G
2.2 Einzelne Daten werden indiziert und die ID wird automatisch inkrementiert und uuidNicht viel andersAuto-Inkrement-ID

0,040

Primärschlüsseltyp SQL-Anweisung td>

Ausführungszeit (Sekunden)
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

Automatische Inkrementierung 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');

Auto-Inkrement-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

2.3 BereichwieAbfrage, automatische Inkrementierung ID schneidet besser ab als 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; 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
Primärschlüsseltyp 		SQL-Anweisung Ausführungszeit (Sekunden)

(1) Fuzzy-Bereichsabfrage 1000 Teile der Daten ist die Leistung der selbsterhöhenden ID besser als die der UUID

Selbsterhöhende 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 td>
(2) Datumsbereichsabfrage 20 Datenelemente, die automatisch Inkrement-ID ist etwas schwächer als UUID td>
Auto-Inkrement-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
UUID0,543
(3) Bereichsabfrage für 200 Daten, die Leistung der automatisch inkrementierten ID ist besser als die von UUID
Auto-Inkrement-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
Bereichsabfrage Gesamtmenge, Auto-Inkrement-ID ist besser als UUID
Auto-Inkrement-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

PS: Bei Vorhandensein eines Caches gibt es keinen kleinen Unterschied in der Ausführungseffizienz zwischen den beiden.

2.4 Test schreiben, automatische Inkrementierung ID ist 4 mal

Primärschlüsseltyp UPDATE test.`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 test.`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' ;Auto-Inkrement-IDINSERT INTO test.`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-Anweisung

Ausführungszeit (Sekunden)

ID automatisch inkrementieren

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` ; `,   `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` )) `,   `ACTIVATE_TYPE` FROM `test`.`UC_USER_1`  LIMIT 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 test UC_USER_500> UC_USER_500.sql28,59秒

UUIDtime mysqldump -utim -ptimgood  -h192.168.121.63 test UC_USER_PK_VARCHAR_500> UC_USER_PK_VARCHAR_500.sql31.08秒

 

MySQL-Datenbank

自增IDtime mysql  -utim -ptimgood -h192.168.121.63  test < UC_USER_500.sql<🎜><🎜><🎜><🎜>7m36.601s<🎜><🎜><🎜><🎜><🎜>UUID<🎜><🎜><🎜><🎜>Zeit mysql  -utim -ptimgood -h192.168.121.63  test < UC_USER_PK_VARCHAR_500.sql<🎜><🎜><🎜><🎜>9m42.472s<🎜><🎜><🎜><🎜><🎜> <🎜><🎜>< 🎜><🎜> <🎜><🎜><🎜><🎜> <🎜><🎜><🎜><🎜><🎜>

3, 500WZusammenfassung

Unter dem Test der 500-W-Datensatztabelle:

(1) Für den normalen Abruf einzelner oder etwa 20 Datensätze ist die UUID der Primärschlüssel. Die Effizienz ist fast gleich;

(2) Bei Bereichsabfragen, insbesondere bei Hunderten oder Tausenden von Datensätzen, ist die Effizienz der automatischen Inkrementierung von IDs größer als bei

(3). Bei Bereichsabfragen ist die Effizienz der selbsterhöhenden ID größer als die von uuid. (4) In Bezug auf den Speicher beträgt der von der selbsterhöhenden ID belegte Speicherplatz die Hälfte von uuid.

(5) In Bezug auf Sicherung und Wiederherstellung ist der automatisch inkrementierende ID-Primärschlüssel etwas besser als UUID.

4

、1000WDatentest

4.1

Eingang1000WDatensatz, siehe Speicherplatz<🎜><🎜>自增ID<🎜><🎜><🎜><🎜>time mysqldump -utim -ptimgood -h192.168.121.63  test UC_USER_1> UC_USER_1.sql0m50.548s

UUIDZeit mysqldump -utim -ptimgood  -h192.168.121.63 test UC_USER_PK_VARCHAR_1> UC_USER_PK_VARCHAR_1.sql0m58.590s自增IDtime mysql -utim -ptimgood  -h192.168.121.63 test < UC_USER_1.sql<🎜><🎜><🎜><🎜>17m30.822s<🎜><🎜><🎜><🎜><🎜>UUID<🎜><🎜><🎜><🎜>Zeit mysql -utim -ptimgood  -h192.168.121.63 test < UC_USER_PK_VARCHAR_1.sql<🎜><🎜><🎜><🎜>23m6.360s<🎜><🎜><🎜><🎜><🎜> <🎜><🎜>< 🎜><🎜> <🎜><🎜><🎜><🎜> <🎜><🎜><🎜><🎜><🎜>

5, 1000WZusammenfassung

Unter dem Test der 1000-W-Datensatztabelle:

(1) Für den normalen Abruf einzelner oder etwa 20 Datensätze beträgt die Effizienz der automatischen Inkrementierung des Primärschlüssels das Zwei- bis Dreifache die des UUID-Primärschlüssels;

(2) Bei Bereichsabfragen, insbesondere für Hunderte oder Tausende von Datensätzen, ist die Effizienz der automatischen Inkrementierung von IDs jedoch größer als bei

(3). Bei der statistischen Zusammenfassung für Bereichsabfragen beträgt die Effizienz des automatisch inkrementierenden ID-Primärschlüssels das 1,5- bis 2-fache der Effizienz des UUID-Primärschlüssels Die automatisch inkrementierende ID beträgt die Hälfte der UUID. (5) In Bezug auf das Schreiben beträgt die Effizienz des automatisch inkrementierenden ID-Primärschlüssels das Drei- bis Zehnfache des UUID-Primärschlüssels ist offensichtlich, insbesondere wenn Daten in einem kleinen Bereich aktualisiert werden.

(6) In Bezug auf Sicherung und Wiederherstellung ist der selbsterhöhende ID-Primärschlüssel etwas besser als UUID.

6

,

MySQLVerteilte Architektur KompromisseDie verteilte Architektur bedeutet, dass die Einzigartigkeit des Primärschlüssels einer Tabelle in mehreren Instanzen beibehalten werden muss. Derzeit ist der gewöhnliche Primärschlüssel mit einer selbsterhöhenden ID für eine einzelne Tabelle nicht geeignet, da bei mehreren MySQL-Instanzen das Problem der globalen Eindeutigkeit des Primärschlüssels auftritt.

6.1

, automatische Inkrementierung

ID Primärschlüssel + Schrittgröße, geeignet für mittelgroße verteilte Szenarien Auf dem Master jeder Clusterknotengruppe, Stellen Sie (auto_increment_increment) ein, versetzen Sie den Startpunkt jedes Clusters um 1 und wählen Sie eine Schrittgröße, die größer ist als die Anzahl der geteilten Cluster, die in Zukunft grundsätzlich nicht mehr erreicht werden kann, um den Effekt einer relativen Segmentierung der zu erfüllenden ID zu erzielen der globale einzigartige Effekt.

Die Vorteile sind: einfache Implementierung, einfache Nachwartung und Transparenz für die Anwendung.

Der Nachteil ist: Die erste Einrichtung ist relativ kompliziert, da für die zukünftige Geschäftsentwicklung ausreichende Schrittweiten berechnet werden müssen

;

Planung:

Wenn beispielsweise insgesamt N Knotengruppen geplant sind, dann ist die i- te Knotengruppe Die Konfiguration von my.cnf ist: auto_increment_offset i

auto_increment_increment N

Wenn 48 Knotengruppen geplant sind, ist N 48, Konfigurieren Sie nun die 8. Knotengruppe, dieses i ist 8, die Konfiguration in my.cnf der 8. Knotengruppe lautet:

auto_increment_offset 8

auto_increment_increment 48

6.2

,

UUID, geeignet für kleine verteilte Umgebungen Bei einer geclusterten Primärschlüssel-Engine wie InnoDB werden die Daten nach dem Primärschlüssel sortiert. Aufgrund der Unordnung der UUID erzeugt InnoDB einen enormen E/A-Druck und weil der Index und die Daten zusammen gespeichert werden , strings Der Primärschlüssel verdoppelt den Speicherplatz.

Während des Speicherns und Abrufens sortiert innodb die Primärschlüssel physisch, was eine gute Nachricht für auto_increment_int ist, da die Position des später eingefügten Primärschlüssels immer am Ende liegt. Für UUID ist dies jedoch eine schlechte Nachricht, da UUID chaotisch ist und die Position des Primärschlüssels jedes Mal ungewiss ist. Wenn der Primärschlüssel physisch sortiert ist, führt dies zwangsläufig dazu Eine große Anzahl von E/A-Vorgängen beeinträchtigt die Effizienz. Wenn die Datenmenge weiter wächst, insbesondere wenn die Datenmenge mehrere zehn Millionen Datensätze überschreitet, sinkt die Lese- und Schreibleistung dramatisch.

Vorteile: Der Aufbau ist relativ einfach und erfordert nicht die Eindeutigkeit des Primärschlüssels.

Nachteile: Nimmt doppelt so viel Speicherplatz in Anspruch (es kostet

2

mal mehr für nur ein Stück Cloud-Speicher) und später Die Lese- und Schreibleistung sinkt drastisch.

6.3

, Snowflake-Algorithmus erstellt globale Selbst- erstellt

ID hinzugefügt, geeignet für verteilte Szenarien in Big-Data-Umgebungen Der von Twitter angekündigte Open-Source-Algorithmus für verteilte IDs Snowflake (Java-Version)

IdWorker.java：

#

# 自增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>

Selbstinkrement

id

Tabelle als Primärschlüssel

mysql>

主键类型

数据文件大小

占据容量 

自增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
Datenbank geändertmysql> select count(1) from UC_USER_1;+ - ----------+|. count(1) |+----------+| |+----------+1 Zeile im Satz (27,42 Sek.) # uuid Tabelle mit Primärschlüsselmysql> select count(1) from UC_USER_PK_VARCHAR_1;+----------+ |. count(1) |+---------+10698102 |+------- -- -+1 Zeile im Satz (0,00 Sek.) mysql> Gemessen an der belegten Speicherplatzkapazität ist die Auto-Inkrement-ID etwa halb kleiner als die UUID: Auto-Inkrement-ID
Primärschlüsseltyp Datendateigröße Belegte Kapazität
-rw-rw---- 1 mysql mysql 4,2 G 20. August 23:08 UC_USER_1 .ibd 4,2 G
UUID -rw-rw---- 1 mysql mysql 8.8G 20. August 18:20 UC_USER_PK_VARCHAR_1.ibd td> 8,8 G

4.2 Einzelne Daten werden nach Index abgefragt, automatische Inkrementierung id und uuid beträgt: (2~3):1

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

Abfrage basierend auf dem Datum

Primärschlüsseltyp

主键类型

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-Anweisung

Ausführungszeit (Sekunden). )

Einzeldatensatzabfrage

ID automatisch inkrementieren

0,069
UUID SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` ='14782121512';

0,274

Abfrage für kleine Bereiche

Selbstinkrement-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
Auto-Inkrement-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

4.3 BereichwieAbfrage, automatische Inkrementierung ID schneidet besser ab als UUID, Verhältnis(1,5~2):1

tr>Auto-Inkrement-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
Primärschlüsseltyp 		SQL-Anweisung Ausführungszeit (Sekunden)

(1) Fuzzy-Bereichsabfrage 1000 Datenelemente, Leistung der automatischen Inkrement-ID ist besser als bei UUID td>

Auto-Inkrement-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) Fragen Sie 20 Daten im Datumsbereich ab, und die sich selbst erhöhende ID ist etwas schwächer als UUID
Auto-Inkrement-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) Bereichsabfrage von 200 Daten, die Leistung der automatischen Inkrement-ID ist besser als die von UUID
Auto-Inkrement-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.` 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
Gesamtmenge der Bereichsabfrage, Auto-Inkrement-ID ist besser als 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 Test schreiben, automatische Inkrementierung ID Es ist effizienter als UUID und das Verhältnis beträgt (3~10): 1

Primärschlüsseltyp

SQL-Anweisung

Ausführungszeit (Sekunden)

Datensätze eines Tages ändern

ID erhöhen

UPDATE test.`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 test.`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

Daten eingeben

Auto-Inkrement-ID

INSERT INTO test.`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 test.`UC_USER_PK_VARCHAR_1`(    ID,   „USER_NAME“,   „USER_PWD“, ,   `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`, `spickname`,` stat`, `user_mall`,` last_login_date`, `last_login_ip`,` src_open_user_id`, `E -Mail ', concat (' 110 ', trim (` mobile`` )) ATE`,   `ACTIVATE_TYPE` FROM `test`.`UC_USER_1`  LIMIT 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备份<🎜><🎜><🎜>

 

MySQL-Datenbank

package com.demo.elk; import org.slf4j.Logger; 测试生成ID的测试类，IdWorkerTest.java：

import org.slf4j.LoggerFactory;

     protected static final Logger LOG =  LoggerFactory.getLogger(IdWorker.class);

    

     private long workerId;

     private long datacenterId;

private lange Sequenz = 0L; datacenterIdBits = 5L;

     private long maxWorkerId = -1L ^ (-1L << workerIdBits);

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

     private long sequenceBits = 12L;

 

     private long workerIdShift = sequenceBits;

     private long datacenterIdShift = sequenceBits + workerIdBits;

private long timestampLeftShift = sequenceBits + workerIdBits +  datacenterIdBits;

     private long sequenceMask = -1L ^ (-1L << sequenceBits);

 

     private long lastTimestamp = - 1L;

 

     public IdWorker(long workerId, long datacenterId) {

         // Plausibilitätsprüfung für workerId

         if (workerId > maxWorkerId || workerId < 0). >         if (datacenterId > maxDatacenterId || datacenterId < 0) {

             throw new  IllegalArgumentException(String.format("Datacenter-ID kann nicht größer als %d oder kleiner als 0 sein", maxDatacenterId));

         }

         this.workerId = workerId;

         this.datacenterId = datacenterId;

         LOG.info(String.format("Worker startet. Zeitstempel Linksverschiebung %d,  Datencenter-ID-Bits %d, Worker-ID-Bits %d, Sequenzbits %d, Worker-ID  %d", ZeitstempelLeftShift, datacenterIdBits, workerIdBits, sequenceBits,  workerId));

     }

 

     public synchronisiert long nextId() {

         long timestamp = timeGen();

 

         if (timestamp < lastTimestamp) {

             LOG.error(String.format("Die Uhr bewegt sich rückwärts. Anfragen werden abgelehnt bis %d.",  lastTimestamp));

            throw new  RuntimeException(String.format("Die Uhr wurde rückwärts verschoben.  Weigerung, eine ID für %d  Millisekunden zu generieren, lastTimestamp - Zeitstempel));

         }

 

         if (lastTimestamp == timestamp) {

            Sequenz = (sequence + 1) &  sequenceMask;

            if (sequence == 0) {

                timestamp =  tilNextMillis(lastTimestamp);

            }

         } else {

            sequence = 0L;

         }

 

         lastTimestamp = timestamp;

 

       . zurück (( timestamp - twepoch) << timestampLeftShift) |  (datacenterId << workerIdShift)  | protected long tilNextMillis(long lastTimestamp) {

         long timestamp = timeGen();

         while (timestamp <= lastTimestamp) {

            timestamp = timeGen()

         return  System.currentTimeMillis();

     }

}

 

 

 

Paket com.demo.elk;

 

import java.util.HashSet;

import java.util. Set; 

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();

         }

     }

}

öffentliche Klasse IdWorkerTest {               statische Klasse IdWorkThread implementiert Runnable {        private Set Set; private idworker idworker; 🎜>            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 = neuer Thread(new IdWorkThread(set, idWorker1));        Thread t2 = neuer Thread(new  IdWorkThread(set, idWorker2));         t1.setDaemon(true) ;         t2.setDaemon(true);         t1.start();         t2.start();         try {            Thread.sleep(30000);         } Catch (InterruptedException e) {             e.printStackTrace();         }     }}

7, Zusammenfassung

(1) Einzelne Instanz oder einzelne Knotengruppe:

Nach 500-W- und 1000-W-Standalone-Tabellentests ist die automatische Inkrementierungs-ID besser als die UUID Die Leistung des inkrementellen ID-Primärschlüssels ist höher als die von UUID und die Festplattenspeicherkosten sind halb so hoch wie die von UUID. Daher verwendet auf einer einzelnen Instanz oder einer einzelnen Knotengruppe die automatisch inkrementierende ID als bevorzugten Primärschlüssel.

(2) Verteiltes Architekturszenario:

Die kleinen verteilten Szenarien unter der 20-Knoten-Gruppe können den UUID-Primärschlüssel schnell bereitstellen, wobei mehrere Speicherkosten anfallen und ein Teil der Leistung geopfert wird >

Für mittelgroße verteilte Szenarien mit 20 bis 200 Knotengruppen kann eine schnellere Lösung mit sich selbst erhöhender ID + Schrittgröße verwendet werden.

Verteilte Szenarien unter Big Data mit mehr als 200 Knotengruppen können aus der globalen automatisch inkrementierenden ID lernen, die vom Twitter Snowflake-Algorithmus als Primärschlüssel erstellt wird.

Das Obige ist der detaillierte Prozess des Vergleichs der Vor- und Nachteile der Verwendung des automatisch inkrementierenden ID-Primärschlüssels und der UUID als Primärschlüssel in MySQL (Tests aus Millionen). Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!


Verwandte Etiketten：
MySQL ，UUID ，优劣比较
Quelle：php.cn
Vorheriger Artikel：Anmerkungen zur MySQL-Studie: einfacher als das Schreiben eines SQL-Servers Nächster Artikel：Detaillierter Prozess zum Vergleich der Vor- und Nachteile von MySQL unter Verwendung des automatisch inkrementierenden ID-Primärschlüssels und der UUID als Primärschlüssel (500-W-Einzeltabelle)
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Neueste Artikel des Autors
Aktuelle Ausgaben
function_exists() kann die benutzerdefinierte Funktion nicht ermitteln Funktionstest () {Verwendung der Verwendung durch -Durch -Durch -Durch -Durch -Durch -Durc...
Aus 2024-04-29 11:01:01
0
2
1961
So zeigen Sie die mobile Version von Google Chrome an Hallo Lehrer, wie kann ich Google Chrome in eine mobile Version umwandeln?
Aus 2024-04-23 00:22:19
0
10
2122
Das untergeordnete Fenster bedient das übergeordnete Fenster, aber die Ausgabe antwortet nicht. Die ersten beiden Sätze sind ausführbar, der letzte Satz jedoch nicht.
Aus 2024-04-19 15:37:47
0
1
1790
Im übergeordneten Fenster erfolgt keine Ausgabe document.onclick = function(){ window.opener.document.write('Ich bin die Ausgabe des unter...
Aus 2024-04-18 23:52:34
0
1
1689
Wo gibt es die Kursunterlagen zum CSS-Mindmapping? Kursunterlagen
Aus 2024-04-16 10:10:18
0
0
1697
verwandte Themen
Mehr>
Beliebte Empfehlungen
Beliebte Tutorials
Mehr>
Verwandte Tutorials
Beliebte Empfehlungen
Aktuelle Kurse
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage

Online-PHP-Schulung für das Gemeinwohl，Helfen Sie PHP-Lernenden, sich schnell weiterzuentwickeln！

Über uns Haftungsausschluss Sitemap

© php.cn All rights reserved