php - 避免往返 key 查找

Question

所以我有一个数据库表，许多其他表都依赖于它，这意味着我需要尽早从中获取一个键。问题是，这意味着往返数据库，必要时在表中创建一行并返回键，我想知道是否有任何巧妙的方法可以消除该步骤。

部分问题在于，真正唯一标识每一行的列的长度是可变的，并且可能会很长，因此不适合用作键。以此为例，假设我的所有数据都是基于“域”组织的，为简单起见，假设一个网站域。因此，我可能有两个如下所示的表:

CREATE TABLE `domains` (
    `key` binary(16) NOT NULL DEFAULT X'0000000000000000',
    `name` varchar(255) NOT NULL DEFAULT '',
    PRIMARY KEY (`key`),
    UNIQUE KEY `name` (`name`)
);
CREATE TABLE `users` (
    `domain` binary(16) NOT NULL DEFAULT X'0000000000000000',
    `username` varchar(64) NOT NULL DEFAULT '',
    `email` varchar(255) DEFAULT '',
    PRIMARY KEY (`domain`,`username`)
);

目前要处理此示例中的域，我会执行以下操作:

INSERT IGNORE INTO `domains` (`key`, `name`)
VALUES (UUID_TO_BIN(UUID(), TRUE), a_name);

SELECT `key` FROM `domains` WHERE `name` = a_name;

这工作得很好，但如您所见，它涉及往返；在我的例子中，我立即触发了 INSERT，而不是必须先 SELECT，检查结果然后返回进行另一遍。

可预测的 key

我已经考虑过的一种替代方法是使用 v5 UUID 而不是 v1；本质上是生成 name 列的 SHA-1 散列并将其存储为 key 。这意味着 key 总是可预测的，只知道 name，因此不需要往返。事实上，如果我愿意，我什至可以延迟或跳过 INSERT。

此选项的问题是生成的 UUID 是高度随机的，这对于索引来说并不理想，因为这意味着即使是一小部分域也可能广泛分布在众多索引页面上。索引性能是为什么在上面的示例中，我使用推荐的方法存储 UUID 使用 UUID_TO_BIN(a_uuid, TRUE) 重新排序 v1 UUID 以提高索引性能，因此用高度替换它随 secret 钥似乎是一个糟糕的权衡，特别是如果在我的整个数据库中广泛使用相同的基本 key 。

缓存

另一个明显的替代方法是尝试在我的应用程序中缓存域 key ，这样就不需要查找已知的域。

这个问题是我的应用程序是基于 PHP 的，这意味着我缓存此信息的主要方法是将其存储在文件中(烦人但可行)或用户的 $_SESSION 数组。后者虽然最简单，但依赖于始终有一个可用的 session ID，这并不能保证；即，在没有请求的最坏情况下，我仍然每次都进行完整的往返。

问题

我已经为此苦苦思索了一段时间，因为没有一个选项是我最理想的选择，我不禁摇摇头，觉得可能有一个我不知道的聪明解决方案的。

所以我的问题是；避免这种 key 检索往返的最简单方法是什么？对于我已经考虑过的问题(例如，避免我发现的问题的方法)是否有替代方案或改进方案？

这个问题的解决方案应该完全消除往返，或者在大多数情况下消除往返的需要。

如有必要，我可以尝试提供我的实际系统的更多详细信息，但实际上上面的示例应该涵盖它；即，在我可以执行任何涉及 users 表的操作之前，我需要确定我需要查询的域 key 。

Answer 1

The problem with this option is that the UUID that is generated is highly random, which isn't ideal for indexing, as it means that even a small set of domains could be spread widely over numerous index pages. Index performance is why...

我认为这可能是过早优化的情况。为集合创建的索引将在同一页中保留相邻的键，而不管它们之间缺少的键的数量。不要试图想出数据库。它的优化在 99% 的情况下都是正确的，即使您有稀疏键也是如此。

So I have a database table upon which many other tables are dependent, which means I need to obtain a key from it at the earliest possible opportunity. The problem is, this means a round-trip to the database, creating a row in the table if necessary and returning the key, and I'm wondering about whether there are any clever ways to eliminate that step.

大多数数据库都有一种方法可以自动将顺序 ID 分配给列。在 MySQL 的情况下，该方法是 AUTO_INCREMENT 列。将主表中的 key 列设置为 AUTO_INCREMENT，并且不要在 INSERT 中为该列提供值。然后后续插入可以使用 LAST_INSERT_ID() 为外键列提供一个值。它看起来像这样:

CREATE TABLE `domains` (
    `key` INT NOT NULL AUTO_INCREMENT,
    `name` varchar(255) NOT NULL DEFAULT '',
    PRIMARY KEY (`key`),
    UNIQUE KEY `name` (`name`)
);
CREATE TABLE `users` (
    `domainid` INT NOT NULL DEFAULT 0,
    `username` varchar(64) NOT NULL DEFAULT '',
    `email` varchar(255) DEFAULT '',
    PRIMARY KEY (`domain`,`username`)
);
INSERT INTO `domain` (`name`)
    VALUES ('example.com');
INSERT INTO `users` (`domainid`,`username`,`email`)
    VALUES (LAST_INSERT_ID(),'henryg','henryg@gmail.com');

无需额外访问服务器，服务器会跟踪最后插入的 ID。