ID为2的两个查询比散列的查询快吗？

我有一个表有两列，id和uniqueId，uniqueId是一个TEXT字段，使用PHP的uniqid函数生成。出于安全/隐私的原因，用户永远不会在客户端获得实际的id。ID为2的两个查询比散列的查询快吗？

因此，一个常见的情况是用户请求的详细信息，或儿童领域从另一个表由UNIQUEID他们拥有的资源。

我的问题是这样的，具体而言，我有一个查询将在表中查找50-100个条目，使用uniqueId（类似于55ea74bc12a661.02727647）执行查找，或者首先执行查找查询查找原始ID（简单自动增量列），然后使用该查找执行查找？

来源

2015-09-05 Ecksters

使用MySQL和InnoDB的最快可能的查找是当你使用主键 - 在你的情况下，通过auto_increment查找是最快，没有比这更快的。 –

我想这个问题是否值得招致额外查询的开销。 – Ecksters

如果您添加您正在运行的查询，我们可能会帮助您。这样，这只是猜测。 –

你有两个问题。

用户正在使用long，'random'，uniqueId代码。你需要看看。
当联接表和做其他的查找，您需要一个唯一的ID（无论是id或uniqueId）参加与。

第1步：uniqueId也可能是Users表的主键。它也可以有一个AUTO_INCREMENT我的点＃2的ID。（更多在一分钟之内）。作为PK达到了N.B.带大。

uniqueId VARCHAR(255) NOT NULL CHARACTER SET ascii, -- not TEXT, not utf8 
id INT UNSIGNED NOT NULL AUTO_INCREMENT, 
PRIMARY KEY(uniqueId), 
INDEX(id) -- Yes, auto_inc will work with this

这给你从uniqueId到id的映射，以及获取到用户的基本信息在您的第一SELECT。

第2步：现在你会JOINing使用id其他表。或者使用id分开做SELECTs。为什么不简单地使用uniqueId？

id要小得多 - 只有4个字节。对比uniqueId - 高达257字节。
“更新”的用户将有“更高”的标识。这将倾向于将活动用户“聚类”在一起，使事物更容易被缓存。（我假设“老年人”的用户大部分是从地球上掉下来的。）

来源

2015-09-05 19:44:45

感谢您提出比我更好的问题，另外，我认为您关于将其设置为ASCII码VARCHAR的提示将对我的表现产生巨大影响，所以非常感谢。 – Ecksters

ID为2的两个查询比散列的查询快吗？

回答

相关问题