我有一个 sqlite 数据库，其中所有的主键都是 GUID。目前它们存储为固定长度的字符串，但我想将它们存储为 blob，因为它简化了存储和检索数据的代码。我转换了部分数据库，一切都按预期运行。但是，我不确定是否会遇到性能问题。
例如，这样的语句在字符串上会比在 blob 上更快吗？
SELECT * FROM table1 t1, table2 t2 WHERE t1.id = t2.parent_id
我的直觉说不，但这并不意味着什么。
【问题讨论】：
标签： sql performance sqlite
找出答案的最佳方法是针对分析器/SQLite 的计时器运行查询。设置一个测试并使用字符串运行查询 1000 次，然后作为 blob 运行 1000 次。获胜者是最快的。
直觉是一回事，硬数据是另一回事。
【讨论】：
我认为是 AIEE，如果我是你，我会将 GUID 存储在 SQLITE 上的一对整数类型中（SQLITE INTEGER 是 64 位）。
但是在这种情况下，blob 可能实际上效果更好。
LFSR 是对的，请分析一下。
【讨论】：
主键通常被索引并用于排序。 BLOB 不能被索引，这使它成为所有数据类型中最慢的。事实上，作为主键，它是最糟糕的选择，大多数数据库，包括 SQL99 标准，都不允许它。
BLOB 的问题是数据库不知道它的数据类型（BLOB 只能用于任何未定义的内容，例如徽标、图像、word 文档，只能存储为二进制数据）。因此它无法优化它。另一个问题是显示。 Blob 不能简单地显示为文本。
大多数 SQL 实现不允许比较 BLOB 字段，但 SQLite 允许。但是，它会将您与之比较的任何内容转换为 blob，然后逐位进行比较。
SQLite 中主键列的最佳选择是使用INTEGER PRIMARY KEY，如此处所述；：http://www.sqlite.org/lang_createtable.html#rowid 它提供了最佳性能（它已经作为rowid 列存在，它只是别名） .
回答您的问题：是的，它会严重影响性能。但更重要的是，它会让你很难很好地管理你的桌子。使用INTEGER PRIMARY KEY，它确实是最好的，保证独一无二，而且速度极快。
【讨论】：