Question

我有三个表来定义用户：

USER: user_id (int), username (varchar)
USER_METADATA_FIELD: user_metadata_field_id (int), field_name (varchar)
USER_METADATA: user_metadata_field_id (int), user_id (int), field_value (varchar)

我想创建一个中间层用户，该用户可以访问应用程序中的其他用户。要确定登录使用的用户可以访问哪些用户，我使用的子查询如下：

SELECT user_id FROM user WHERE user_id 
     IN (SELECT user_id 
         FROM user_metadata 
         WHERE user_metadata_field_id = 1 AND field_value = 'foo')

目前，我将子查询字符串存储在变量中，然后在每次需要提取用户列表时将其动态插入到外部查询中。在这样做之后，我想，“只需要存储一串实际的user_id s就可以了。”

所以不要将其存储在变量中......

$subSql = "SELECT user_id FROM user_metadata WHERE user_metadata_field_id = 1 AND field_value = 'foo'";

...我实际执行查询并存储结果......

$subSql = "12, 56, 89, 100, 1234, 890";

然后当我需要拉出登录用户可以访问的点亮用户时，我可以这样做：

$sql = "SELECT user_id FROM user WHERE user_id IN ($subSql)";

最后问题：

您在MySQL IN条款中可以使用多少项？存储实际的id而不是sub-sql语句每次执行外部查询必须更快，对吗？

Answer 1

来自manual：

IN列表中的值数量仅受max_allowed_packet值的限制。

Answer 2

从某个数字开始，IN表格更快。

MySQL在其代码中有一些内容，它使得在大量常量值上构建范围比在嵌套循环中执行相同操作更慢。

请参阅我的博客中有关效果详情的文章：

Passing parameters in MySQL: IN list vs. temporary table

Answer 3

正如Quassnoi的回应中暗示的那样，一个在其他实际考虑因素之前发现了错误，在达到给定MySql版本的实现（*）所施加的任何可能的限制之前。因此，随着管理员用户的数量（或可能需要IN构造的其他标准）的增长，人们应该寻求使用文字“IN”的替代方法，例如使用临时（甚至永久）表。

由于您正在考虑对“管理员用户”标准进行特殊处理，出于性能目的，我想提供评论和建议。

评论：这可能是过早优化的情况吗？我不知道这个数据库的具体细节，它的数量，复杂性等等。是的，我知道要对EAV（实体 - 属性 - 值）格式付出一些性能，但我想即使对于成功的企业，账户数据库也很少超过10,000个用户。因此，即使每个用户拥有非常多的属性，我们仍然会查看相对较小的EAV表，这可能不需要这种类型的优化。（另一方面，其他一些优化技巧可能会受到欢迎。）此外，典型的用例涉及相对于其他查询相对较少的对帐户数据库的查询，这是另一个原因。对应用程序的帐户相关功能进行任何非平凡的性能考虑。

建议：也许使用“重新规范化的属性”
对于单值的属性，特别是如果它们很短，可以在Entity表中移动（或复制）它们（在本例中为'USER'表）。这在插入或更新项时引入了一些逻辑，但这与许多连接（或子查询）相同，并且还提供了考虑多字段索引以支持最常见用例的机会。

（*）有限制吗？我还没有读到任何这样的限制;我知道Oracle有一段时间有1000个限制，MSSQL没有;当然所有服务器都有一个基于SQL语句总长度的限制，但这是一个非常大的数字！如果有人偶然发现那个，他/她还有其他问题...... ;-)

Answer 4

MySQL的IN子句本身没有这样的限制。我尝试了8000个元素，它对我来说很好。堆栈溢出错误可以是变量声明，

Answer 5

如果IN()子句中的值超过1000，MariaDB似乎会自动创建临时表以提高性能。您可以使用EXPLAIN看到它。

MySQL“in clause”中的项目数

5 个答案: