WordPress可以处理多少个用户？

我想在WP中设计一个会员登录网站，但我怀疑WordPress是否可以在同一数据库上处理超过40000个用户？

我对此不太确定，所以我在这里工作。因此，如果有人对此有所了解，请帮助我继续进行WP项目。

根据WP数据库结构，wp_users中的ID为Bigint（20）UNSIGNED，因此您可以“理论上”添加18446744073709551615用户。 http://dev.mysql.com/doc/refman/4.1/en/integer-types.html

回答这个问题有点晚了，但是自从相关搜索出现以来，这对某些人很有用：

WordPress将EAV数据库架构用于其数据库实现的一部分。这会影响数据和用户。（它们保存在单独的表中）

从数据角度进行解释：

连同wp_posts中可直接访问的帖子相关详细信息，每个帖子都将大量元数据发布到wp_postmeta表中。与帖子（或自定义帖子类型）相关的任何数据。

这样做的问题是，如果您拥有帖子或页面的HEAPS（或自定义帖子/数据），则搜索meta中找到的任何属性将变得非常缓慢。您首先在元表中搜索所有条目以查找所需的条件，然后从表中获取相关帖子。更重要的是，您需要分别搜索每个标准。因此，一次搜索标记，您将获得值为'meta1'的X帖子，然后搜索第二个条件（例如customcriteria），并在customcriteria中获得具有customcriteriavalue1的帖子ID，然后取它们的交集，然后得到来自该交叉点的posts表中的post details。

例如，将30,000种产品放入WooCommerce，最终您将在wp_postmeta中获得约1,800,000行，如以下答案所述：

发布元数据表与单独的数据库表

因此，这不仅会使搜索效率非常低（尤其是当您在wp_postmeta上进行自我联接以获取多个条件时），而且甚至从1,8百万行中查询单行都会导致性能下降。

EAV模式不足。

因此，通过大量的帖子，WordPress db的实现使得复杂的搜索非常缓慢。

如果您使用缓存插件，那么运行具有数千个帖子的WordPress网站是完全可行的。您可以走得更多。但是搜索将是一个问题。

............

用户也是如此-wp_usermeta也使用相同的EAV格式。因此，如果您有很多用户，并且有很多插件将各种用户数据存储在wp_usermeta中，那么您将受到同样的性能影响。

更不用说有那么多用户了，您可能已经有很多帖子了-除非您的应用程序主要与用户有关（CRM等），并且您选择将用户数据存储在wp_usermeta中而不是wp_postmeta中。（虽然不太可能）。

......

有一些插件可以解决此问题，例如Meta Accelerator。

https://wordpress.org/plugins/meta-accelerator/

该插件将为您选择的任何给定帖子类型获取任何数据，并将其放在平面表中。这样可以大大加快搜索速度，也可以加快查询任何奇异值的速度。

但是该插件尚处于起步阶段。

或者，您可以在服务器中安装ElasticSearch并使用ElasticPress插件或将其集成到WordPress的另一个插件来加快此类搜索。

我认为您可以运行更多用户。唯一可以限制您的是服务器。您必须正确缩放它，尤其是MySQL服务器。例如，wordpress.com运行了超过40000个用户，但他们使用了功能强大的系统来提高稳定性，负载均衡器等。

问题应该是，由于WP是基于这两种主要技术开发的，因此php-mysql堆栈可以代替WordPress处理多少用户。

话虽这么说，如果您可以使用高级服务器技术配置服务器，将WP托管在良好的托管服务器中，优化数据库负载和查询，则WP可以处理所需的任意数量的成员。

如果在共享主机中安装wordpress，则将限制WP功能。另一方面，如果您可以管理自己从基于云的服务器或专用托管服务器上运行的WP，则应该获得所需的结果。

Wordpress能够处理复杂的数据库采石。您可以查看此https://codex.wordpress.org/Installing_WordPress

还可以将wordpess用作高级应用程序开发框架，从而使您能够进行安装来处理大型/复杂的数据库负载。

您也可以选择以下系列：http : //code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015

希望这会有所帮助。谢谢

我发现可以拥有多少Wordpress用户的瓶颈是用户管理页面上发生的PHP超时。

假设您的所有用户至少具有1个角色，那么他们wp_capabilities在user_metadata表中都有一个带有序列化角色数组的条目。

管理页面显示了每种角色类型的用户数量，因此它必须加载每个wp_capabilities序列化数组，对其进行反序列化，然后显示总数。

当我有300,000个用户时，用户管理页面将花费44秒来构建。

这意味着每个用户都将0.00014666666秒添加到页面加载时间。

假设您的PHP超时时间为60秒，则该限制约为40万名用户。

但是，我正在运行一台非常老旧且缓慢的服务器。更快的硬件将大大改善性能。