应用错误收集

我正在开发一个项目，我需要在数据库（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，使用常规INT作为主键并将UUID作为辅助UNIQUE索引通常是有利的。这主要是因为我认为MySQL在所有二级索引中使用主键作为行标识符，并且此处具有大值可能导致更大的索引大小。做一些大规模的测试，看看这是否会对你产生影响。

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

在任何一种情况下，您都可能希望将UUID表达为文本，以便人类可读，并且可以轻松地操作数据。将二进制数据粘贴到查询中很困难，例如，必须执行简单的UPDATE查询。它还将确保您可以导出或从JSON导入，而不会产生大量的转换开销。

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

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

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

1 个答案: