首页 文章

Mysql：MyIsam或InnoDB，当UUID用作PK时

提问于
浏览 次
2

我正在开发一个项目，我需要在数据库（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？

提前谢谢了 .

mysql innodb uuid myisam

1 回答

  • 1

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

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

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

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

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

    回复于

相关问题