Mysql:MyIsam或InnoDB,当UUID用作PK时

我正在开发一个项目,我需要在数据库(MySQL)中使用UUID(16位)作为唯一标识符 . 数据库有很多关系表 . 关于将UUID用作PK,我有以下问题:

  • 我应该将唯一标识符索引为PK / FK还是没有必要?如果我索引它,索引大小会增加,但它确实需要吗?

附上我必须使用uuid的示例:具有一个唯一标识符(oid)和外键(语言)的表用户 .

CREATE TABLE用户(
oid binary(16)NOT NULL,
username varchar(80),
f_language_oid binary(16)NOT NULL,
PRIMARY KEY (oid),
KEY f_language_oid(f_language_oid),
)ENGINE = InnoDB DEFAULT CHARSET = utf8 COLLATE = utf8_bin;

是否有必要将“oid”定义为PRIMARY_KEY,将语言定义为FOREIGN_KEY,或者如果我只创建没有键定义的表,它会更好吗?

我在这篇文章中读到(here),innodb将自动生成一个6位整数als主键(隐藏) . 在这种情况下,使用6位内部pk比使用16位二进制密钥更好?

  • 如果不需要索引,我应该使用MyISAM还是InnoDB?

提前谢谢了 .

回答(1)

2 years ago

使用MySQL,使用常规 INT 作为主键并将UUID作为辅助 UNIQUE 索引通常是有利的 . 这主要是因为我认为MySQL在所有二级索引中使用主键作为行标识符,并且此处具有大值可能导致更大的索引大小 . 做一些大规模的测试,看看这是否会对你产生影响 .

使用UUID作为主键的一个原因是,如果您尝试在多个独立数据库之间传播数据并希望避免主键冲突 . UUID是一个很好的方法 .

在任何一种情况下,你都是人类可读的,并且很难将二进制数据粘贴到你的查询中,例如,必须做一个简单的 UPDATE 查询 . 它还将确保您可以导出或从JSON导入,而无需大量的转换开销 .

至于MyISAM与InnoDB,在数据完整性和正常运行时间很重要的 生产环境 环境中使用旧的MyISAM数据库是非常不明智的 . 如果数据库损坏,该引擎可能会遭受灾难性数据丢失,像意外重启这样简单的事情可能会导致此问题,并且无法恢复 . InnoDB是一个现代化的日志式事务数据库引擎,具有更强的弹性,可以自动从大多数突发故障情况中恢复,甚至数据库崩溃 .

还有一个考虑因素是评估PostgreSQL是否合适,因为它具有本机UUID列类型 .