桌子太多；MySQL在一个联接中只能使用61个表

您正在使用EAV设计，并尝试根据可变数量的属性来重构单行。这指出了使用EAV设计将遇到的众多地雷之一：在单个SQL查询中可以执行的连接数量有实际限制。

正如您所发现的，尤其是在MySQL中-有一个硬限制。但是，即使在其他RDBMS品牌中，也存在有效的限制，因为联接的成本相对于表的数量是几何的。

如果您使用EAV， 请不要 像在常规数据库设计中 那样尝试在SQL中重新构造行
。取而代之的是，将属性按行获取，并按实体ID排序。然后在您的应用程序代码中对它们进行后处理。这确实意味着您不能一步一步地转储数据-
您必须编写代码以遍历属性行，并在输出数据之前对每一行数据进行重新格式化。

EAV不是方便的数据库设计。使用它有许多昂贵的缺点，而您已经遇到了其中之一。

有关使用EAV如何注定一个企业的伟大故事，请参见http://www.simple-talk.com/opinion/opinion-
pieces/bad-carma/
。

另外，请参阅http://en.wikipedia.org/wiki/Inner-
platform_effect，因为EAV是此反模式的一个示例。

我了解需要支持目录中每个产品的动态属性集。但是，EAV会杀死您的应用程序。这是我支持动态属性的操作：

• 在基本表中为所有产品类型共有的每个属性定义一个实列。产品名称，价格，库存数量等。努力想象规范的 产品 实体，以便您可以在此集中包含尽可能多的属性。

• TEXT

  为每种给定产品类型的所有其他属性定义一个类型列。以适合您的格式存储在此列中，作为属性的序列化LOB：XML，JSON，YAML，您自己的自制DSL等。

将此视为SQL查询中的单个列。根据这些属性进行的任何搜索，排序或显示操作，都需要将整个

TEXT