Raison du test
Un collègue de développement a créé un cadre dans lequel la clé primaire est uuid. Je lui ai suggéré que MySQL ne devrait pas utiliser uuid et que l'utilisation de la clé primaire à incrémentation automatique est plus efficace. ce n'est pas nécessairement élevé. J'ai dit innodb index. La fonctionnalité a conduit à l'utilisation la plus efficace de l'ID auto-incrémenté comme clé primaire. Afin de le convaincre, je me suis préparé à faire un test détaillé.
En tant que société Internet, il doit y avoir une table utilisateur, et la table utilisateur UC_USER en compte essentiellement des millions des enregistrements. Par conséquent, le test est effectué sur la base des données de quasi-test basées sur ce tableau.
L'environnement approximatif est : Centos6.5, MySQL5.6.12
UC_USER, ID d'incrémentation automatique comme clé primaire :
CREATE TABLE `UC_USER` ( |
Table UC_USER_PK_VARCHAR, ID de chaîne comme clé primaire, en utilisant uuid
`ID` varchar(36) JEU DE CARACTÈRES utf8mb4 NON NULL PAR DÉFAUT '0' COMMENTAIRE 'Clé primaire', `USER_NAME` varchar(100) COMMENTAIRE NULL PAR DÉFAUT 'Nom d'utilisateur', `USER_PWD` varchar(200) COMMENTAIRE NULL PAR DÉFAUT 'Mot de passe', `BIRTHDAY` datetime COMMENTAIRE NULL PAR DÉFAUT 'Anniversaire', `NOM` varchar(200) COMMENTAIRE NULL PAR DÉFAUT 'Nom', `USER_ICON` varchar(500) COMMENTAIRE NULL PAR DÉFAUT 'Image d'avatar', `SEX` char(1) NULL PAR DÉFAUT COMMENT 'Sexe, 1 : Homme, 2 : Femme, 3 : Confidentiel', `NICKNAME` varchar(200) DEFAULT NULL COMMENT 'Pseudo', `STAT` varchar(10) DEFAULT NULL COMMENT ' Statut de l'utilisateur, 01 : normal, 02 : gelé', `USER_MALL` bigint(20) DEFAULT NULL COMMENT 'Current MALL', `LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT 'Dernière heure de connexion', /> `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT 'Dernière adresse IP de connexion', `SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT 'Source de connexion conjointe', `EMAIL` varchar( 200) COMMENTAIRE NULL PAR DÉFAUT 'Boîte aux lettres', `MOBILE` varchar(50) COMMENTAIRE NULL PAR DÉFAUT 'Téléphone mobile', `IS_DEL` char(1) COMMENTAIRE PAR DÉFAUT '0' 'Supprimer', `IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT 'S'il faut lier une adresse e-mail', `IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT 'S'il faut lier un téléphone mobile', `CREATER` bigint (20) DEFAULT NULL COMMENT 'Créateur', `CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT 'Heure d'enregistrement', `UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT 'Date de modification', `PWD_INTENSITY` char(1) COMMENTAIRE NULL PAR DÉFAUT 'Force du mot de passe', `MOBILE_TGC` char(64) COMMENTAIRE NULL PAR DÉFAUT 'ID de connexion du téléphone portable', `MAC` char(64 ) COMMENTAIRE NULL PAR DÉFAUT 'adresse mac', `SOURCE` char(1) COMMENTAIRE PAR DÉFAUT '0' '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:Système de gestion, 0:Inconnu ', `ACTIVATE `char(1) DEFAULT '1' COMMENT 'Activation, 1 : activé, 0 : non activé', `ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT 'Type d'activation , 0 : automatique, 1 : manuel ', CLÉ PRIMAIRE (`ID`), CLÉ UNIQUE `USER_NAME` (`USER_NAME`), CLÉ `MOBILE` (`MOBILE`) , CLÉ `IDX_MOBILE_TGC ` (`MOBILE_TGC`,`ID`), CLÉ `IDX_EMAIL` (`EMAIL`,`ID`), CLÉ `IDX_CREATE_DATE` (`CREATE_DATE`, `ID`), KEY `IDX_UPDATE_DATE` (`UPDATE_DATE`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Table utilisateur'; |
Déterminer le volume de données des deux tables
| compte(1) | ---------- | 5720112 | ---------- 1 ligne dans l'ensemble (0,00 sec) mysql> # Table avec uuid comme clé primairemysql> select count(1 ) from UC_USER_PK_VARCHAR_1;>| 5720112 |
|
Type de clé primaire | Taille du fichier de données | Capacité occupée strong> |
ID à auto-incrémentation | -rw -rw---- 1 mysql mysql 2.5G 11 août 18:29 UC_USER.ibd | 2.5 G |
UUID | -rw-rw---- 1 mysql mysql 5.4G 15 août 15 : 11 UC_USER_PK_VARCHAR_1.ibd | 5.4 G |
Type de clé primaire | Instruction SQL td> | Durée d'exécution (secondes) |
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 |
|
||
Incrémentation automatique 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'); | 0,040 |
|
||
ID d'incrémentation automatique | 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 |
|
Instruction SQL | Durée d'exécution (secondes) | |||||||||||||||||||||||||||||||||||||||
(1) Requête de plage floue 1000 pièces des données, les performances de l'ID auto-croissant sont meilleures que celles de l'UUID | |||||||||||||||||||||||||||||||||||||||||
ID auto-croissant | 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) Requête de plage de dates 20 données, l'ID d'incrémentation automatique est légèrement plus faible que l'UUID | |||||||||||||||||||||||||||||||||||||||||
ID d'incrémentation automatique | 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) Interrogation de plage 200 éléments de données, les performances d'identification par incrémentation automatique sont meilleures que l'UUID | |||||||||||||||||||||||||||||||||||||||||
ID d'incrémentation automatique | 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 | ||||||||||||||||||||||||||||||||||||
Quantité totale de la requête de plage, l'ID à incrémentation automatique est meilleur que l'UUID | |||||||||||||||||||||||||||||||||||||||||
ID d'incrémentation automatique | 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 OÙ t.`CREATE_DATE` > '2016-07 -01 10:26:36' ; | 1.092 td> |
PS : En présence de cache, il n'y a pas de petite différence d'efficacité d'exécution entre les deux.
Instruction SQL |
Temps d'exécution (secondes) |
|
||
|
|
ID à incrémentation automatique | 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 |
||||
|
ID à incrémentation automatique | INSÉRER 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` , `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`, ` )), `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` LIMIT 100 ; |
0,424 |
在500W记录表的测试下:
(1) 普通单条或者20条左右的记录检索,uuid为主键的相差不大几乎效率相同;
(2) 但是范围查询特别是上百成千条的记录查询,自增id的效率要大于uuid;
(3) 在范围查询做统计汇总的时候,自增id的效率要大于uuid;
(4) 在以上就是MySQL 使用自增ID主键和UUID Batterie de cuisine (500 W)单表)的内容,更多相关内容请关注PHP中文网(www.php.cn)!