从MYSQL数据库中选择条件为空、一个userId或userId列表的列的最有效方法是什么

我有一个表，它有userId和一个长文本属性。如下:

该表包含大约200万行，需要为给定的userId选择行（并且所有具有userId的行都为NULL）。由于有三种类型的行的UserId为NULL，因此UserId只有一个值，UserId有多个UserId，它们之间用“/”分隔。（我知道分离这些值和规范化表格是好的，但这是要求。） 所以我的问题是什么是检索行的合适方法。现在我实施了两种方法,

“从用户ID为“%”+userId+“%”或用户ID为空的用户中选择*”

将userId具有值列表的行分隔到另一个表中，并使用

“SELECT*from user1，其中userId=”“+userId+””或userId为NULL”

从第一个表中检索行，然后使用like查询从第二个表中检索行（

“SELECT*from user2，其中userId类似“%”+userId+“%”“

）

---

Bot方法也有同样的效率。那么还有其他方法吗？或者这些方法有什么改进吗？

如果您真的、真的坚持保持当前表的原样，并且故意选择不规范化数据库，那么我所能建议的就是创建另一个表，以“规范化”此特定查询的“用户”值。创建一个新表，该表保存当前存储在

UserId

字段中的规范化值，并在特定查询中使用新创建的表

在这种情况下：你可以吃蛋糕，也可以吃蛋糕！您可以开始数据库规范化工作，但现在还不需要删除当前的

UserId

字段。您需要确保（UserId字段和新创建的带有FK的表）保持“同步”，但除此之外，您应该可以继续。您可以“缓慢地迁移”到使用新创建的表，当您的应用程序不再依赖于

/

-分隔的

UserId

字段时，您可以删除该列。同时，对于正在处理的新（er）代码（包括当前查询），您可以从（更好的）规范化数据库中获得好处

---

当然，还要确保新创建的表具有正确的索引，以进一步提高查询的性能。

永远不要存储这样的数据（/separateditems.）。。。这只会给你带来很多麻烦。id使用整数，每行使用一个值！我只能建议你看看，因为你目前的设计很糟糕。如果你解决了这个问题，那么你目前遇到的问题也会得到解决。因此：创建一个新表，该表对用户有一个FK，对数据有另一个FK（params？），并使用该（新创建的）表使用联接选择所需的结果。另外：像%…%这样的

总是会执行糟糕的操作（正确规范化后也会解决/不必要）。是的，这是一个糟糕的设计。我同意。因为对于一个给定的param1，可能有数千个用户ID，可能有数百万个param1条目，所以我们的小组成员建议使用这种方法。我们需要在一秒钟内实现20000 db的调用。将数据库“重构”到一个适当规范化的版本可能需要一些额外的工作，但从长远来看，这将始终比使用当前的数据库要好。现在解决这个问题比以后（或永远）解决好。不管怎样，你都有可能做到这一点（这不是不可能的，也不是很难），但一开始表现会很糟糕。少听你的团队成员的话。：-）