表的大小不是真正的问题，您在该表上运行的查询可能是。

例如，如果您根据存储在用户元表中的数据选择用户，那么该查询将高度未优化，因为meta\\u值不是索引字段。在这种情况下，您可能需要添加额外的索引或考虑以不同的方式存储特定数据，例如使用自定义分类法。

一般来说，你存储为元的东西永远不应该是你专门搜索的东西。这适用于WordPress中的所有元表。Meta主要设计为通过Meta\\u键拉出，而不是通过Meta\\u值拉出。分类法将可能的值限制在一个集合中，并以不同的方式组织信息，因此当“值”作为您选择的值时，分类法会做得更好。

注意，通过meta\\u键和meta\\u值进行选择通常是可以的，因为mySQL将首先优化基于meta\\u键的查询，从而将要搜索的数据量减少到（希望）可管理的限度。如果这成为一个问题，您可以通过向元表中添加一个新索引来“修复”它，该索引上有meta\\u键和meta\\u值，但是由于meta\\u值是长期的，您需要根据您的数据将该索引的长度限制在合理的范围内，如20-30或其他。请注意，此索引可能比实际数据大得多，并且会大幅增加所需的存储空间。然而，在这些类型的查询中，它会快得多。如果这成为一个真正的问题，请咨询合格的DBA。

仅供参考，请访问WordPress。org我们注册了大约1100万用户。每个用户的元数据数量各不相同，每个用户可能至少有8行，最多大约250行。users表约为2.5 GB，usermeta表约为4 GB。大多数情况下，似乎运行正常，但偶尔我们会发现一些奇怪的查询，需要进行优化。