我的应用程序数据库 (MySQL) 中有一个连接表，它大量增长。
我有 2 个模型用户和产品，用户有很多产品要查看，产品属于许多用户如何查看。
开始时，所有用户都可以查看所有产品，并且用户可以编辑他可以查看的产品。
表大小将是 (n*m) n 是用户数（很大），m 是产品数（也很大）的问题，并且对表的读取操作会很慢。
示例：我有 3 个用户的 id 为：“1,2,3”
，3 个产品的 id 为：“1,2,3”
所以 users_products 表将是：
user_id, product_id
1 , 1
1 , 2
1 , 3
2 , 1
2 , 2
2 , 3
3 , 1
3 , 2
3 , 3
我对所有解决方案持开放态度，从重新设计此部分以使用另一个数据库系统开始。
提前致谢。
我认为你假设的东西可能不是真的。即使有很多行，SQL 服务器也能快速处理这类查询。如果您有良好的索引，则可以快速查询具有 1000 万条记录的表。
在进行各种过早的优化之前，我建议您进行一些测试。
你看过 Neo4J 吗？这是一个有据可查的图形数据库，我认为它非常适合这个特定的用例。您进行建模的方式非常简单。
每个用户和每个产品都由一个节点表示。您要么在它们之间创建关系“IS_ABLE_TO_SEE”，要么不创建。
然后，您可以使用一系列功能再次检索此数据。我最喜欢的是使用遍历，从一个节点开始，然后遍历关系（您可以选择要遍历的关系和方向）。但是，这对于检索彼此相距几个深度的数据更有用。
在我们的特定用例中，您可以执行一个简单的查询，返回通过关系“IS_ABLE_TO_SEE”连接到您的用户节点的所有产品节点。
Neo4J 非常适合没有图形数据库经验的人使用，正如我所说，它非常适合您在此处展示的用例。
正如 Pieter-Jan 指出的 Neo4J 有替代解决方案，我是 Couchbase 和 Neo4J 的忠实粉丝。这是一个简单的列表，关系表不太适合这些操作。
在 Couchbase 中，您可以通过多种方式执行此操作，一种是使用简单的 client.append 来保留产品列表，然后使用单个 client.get 来检索列表。有了这个，有两种可能性，在追加之前进行重复数据删除，或者在之后进行重复数据删除。获取列表的速度非常快，将消除任何形式的查询。
另一种方法是使用 JSON，并拥有一个用户可以访问和查看的每个产品的数组，等等。与上面第一个示例中的简单字符串相同，除非你可以在它上执行 Map/Reduce JSON，如果需要。
在这两种情况下，它都会胜过任何类型的查询。