WordPress usermeta可扩展数千个用户

我已经为与WordPress用户管理集成的客户端开发了CRM插件，并在wp_usermeta表格下存储了每个用户的其他信息。

但是，客户的客户数据库正在成倍增长，而我们现在已经成千上万，这使我们有成千上万的行wp_usermeta：在这一点上，我开始担心此体系结构的可伸缩性。

有没有人有过以WordPress方式管理这么多用户的经验？我应该在wp_users表中添加列而不是依赖列wp_usermeta吗？我现阶段如何诊断/分析WordPress和我自己的代码性能？

我从来没有研究过如此大量的数据，而且这种增长的速度，任何指针都是有价值的。

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

例如，如果您基于存储在user-meta表中的数据来选择用户，则该查询将高度未被优化，因为meta_value不是索引字段。在这种情况下，您可能需要添加额外的索引或考虑以其他方式（例如自定义分类法）存储该特定数据。

一般而言，您存储为元数据的内容绝不应成为您将仅基于其进行搜索的内容。这适用于WordPress中的所有元表。Meta主要设计为由meta_key而不是meta_value提取。分类法将可能的值限制为一个集合并以不同的方式组织信息，因此当“值”作为您选择的内容时，分类法会做得更好。

请注意，同时选择meta_key和meta_value都可以，因为mySQL会将查询优化为首先基于meta_key，从而将搜索的数据量减少到（希望）可管理的限制。即使这成为问题，您也可以通过在索引表上同时添加带有meta_key和meta_value的新索引来“修复”它，但是由于meta_value是LONGTEXT，因此您需要将该索引的长度限制为合理，例如20到30左右，取决于您的数据。请注意，此索引可能比实际数据大得多，并且将大大增加所需的存储空间。但是，在这些类型的查询上它将更快。如果这成为实际问题，请咨询合格的DBA。

作为参考，在WordPress.org上，我们注册了大约1100万用户。每个用户的meta数量各不相同，每个用户可能最少有8行，最大可能约为250 ish。用户表约为2.5 GB，用户表约为4 GB。似乎可以正常运行，但大部分时候，我们偶尔会发现一些必须优化的奇数查询。

除非您运行自己的查询而不使用API​​，否则表的大小无关紧要，因为wordpress通过表的索引运行查询，而MYSQL应该优化这种查询。每个查询还可以在一个查询中获取所有元信息。

如果您坚持要使用用户ID上的哈希作为表名，可以将用户元表拆分为几个表，但是您可能必须对wp_db类写一个替换，以根据查询访问正确的表。如果您对遵循此路径感兴趣，请寻找用于处理许多博客的大型网络安装的解决方案。

但是，如果您现在没有任何性能问题，那么无需进行任何重大调整即可进一步提高性能。当您开始遇到性能问题时，只需将数据库移到更快的服务器上，它将比您对WP访问该信息的方式所能进行的任何处理都更具成本效益。