Heim >Datenbank >MySQL-Tutorial >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)
Grund für den Test
Ein Entwicklungskollege hat ein Framework erstellt, in dem der Primärschlüssel uuid ist. Ich habe ihm vorgeschlagen, dass die automatische Inkrementierung des Primärschlüssels effizienter ist Es ist nicht unbedingt hoch, dass die Funktion „innodb index“ zur effizientesten Verwendung der automatisch inkrementierenden ID als Primärschlüssel geführt hat. Um ihn 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.
Die ungefähre Umgebung ist: Centos6.5, MySQL5.6.12
CREATE TABLE `UC_USER` ( |
UC_USER_PK_VARCHAR-Tabelle, String-ID als Primärschlüssel, unter Verwendung von uuid
`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'; |
Bestimmen Sie das Datenvolumen der beiden Tabellen
|. count( 1) | +---------+ | 5720112 | +------- ---+1 Zeile im Satz (0,00 Sek.) mysql> # Tabelle mit UUID als primär key mysql> select count(1) from UC_USER_PK_VARCHAR_1; -------+
|
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 |
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 |
|
SQL-Anweisung | Ausführungszeit (Sekunden) | |||||||||||||||||||||||||||||||||||||||
(1) Fuzzy-Bereichsabfrage 1000 Teile von Daten, Die Leistung der selbsterhöhenden ID ist 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 Daten, Auto-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 | |||||||||||||||||||||||||||||||||||||||
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) 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` > -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 | ||||||||||||||||||||||||||||||||||||
Gesamtmenge der Bereichsabfrage, ID für automatisches Inkrementieren 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 td> |
PS: Bei Vorhandensein eines Caches gibt es keinen kleinen Unterschied in der Ausführungseffizienz zwischen den beiden.
SQL-Anweisung |
Ausführungszeit (Sekunden) |
|
||
|
|
ID automatisch inkrementieren | 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' ;||
1.419 |
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' ; | ||
5.639 |
||||
|
Auto-Inkrement-ID | INSERT 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; | ||
0,105 |
UUID | 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`, `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; |
0,424 |
在500W记录表的测试下:
(1) 普通单条或者20条左右的记录检索,uuid为主键的相差不大几乎效率相同;
(2) 但是范围查询特别是上百成千条的记录查询,自增id的效率要大于uuid;
(3) 在范围查询做统计汇总的时候,自增id的效率要大于uuid;
(4) 在存储上面,自增id所占的存储空间是uuid的1/2;
以上就是MySQL 使用自增ID主键和UUID 500 W单表)的内容,更多相关内容请关注PHP中文网(www.php.cn)!