非共享主机下WordPress数据库连接过多问题排查求助

咱们先拆解你遇到的核心矛盾：MySQL的max_connections设到了1000，但仅50连接/秒的测试就触发了Too many connections，而且SHOW PROCESSLIST看不到长期挂起的查询——这说明问题大概率不是慢查询导致的连接堆积，而是连接复用失效或者连接泄漏，再结合禁用插件后仍有失败率的情况，咱们一步步排查：

一、先搞懂为什么1000连接还不够？ #

max_connections是MySQL允许的同时在线连接数，而你测试的50连接/秒是每秒新发起的请求。如果每个请求都创建1个以上的新连接，且连接没有被及时复用或释放，那么连接数会快速累积：比如每个请求创建2个连接，50请求/秒的话，10秒就会有1000个连接，直接触发上限。

二、针对性调试方案 #

1. 检查插件是否创建独立数据库连接 #

有些插件为了“方便”，会绕过WordPress自带的$wpdb对象，手动用mysqli_connect或PDO创建新连接——这会导致连接无法被WordPress的连接管理机制复用，直接耗尽连接池。你可以用两种方法排查：

方法1：跟踪数据库线程ID变化

在wp-config.php末尾添加一段调试代码，记录关键节点的数据库连接ID（每个连接对应唯一的线程ID）：

// 记录初始连接ID
add_action('init', function() {
    global $wpdb;
    if (is_object($wpdb->dbh)) {
        $thread_id = mysqli_thread_id($wpdb->dbh);
        error_log("[DB Debug] Initial thread ID: {$thread_id}");
    }
});

// 跟踪WooCommerce初始化后的连接ID
add_action('woocommerce_init', function() {
    global $wpdb;
    if (is_object($wpdb->dbh)) {
        $thread_id = mysqli_thread_id($wpdb->dbh);
        error_log("[DB Debug] After WooCommerce init, thread ID: {$thread_id}");
    }
});

// 跟踪所有插件加载后的连接ID
add_action('plugins_loaded', function() {
    global $wpdb;
    if (is_object($wpdb->dbh)) {
        $thread_id = mysqli_thread_id($wpdb->dbh);
        error_log("[DB Debug] After all plugins loaded, thread ID: {$thread_id}");
    }
});

然后查看服务器的PHP错误日志（一般在/var/log/apache2/error.log或/var/log/php-fpm/目录下），如果某个插件加载后线程ID变化，说明它创建了新连接。

方法2：开启MySQL通用日志

临时开启MySQL的通用日志，记录所有连接和查询：

SET GLOBAL general_log = 1;
SET GLOBAL general_log_file = '/var/log/mysql/general.log';

运行JMeter测试几分钟后关闭日志：

SET GLOBAL general_log = 0;

查看日志里的Connect条目，统计每个来源（比如PHP进程）的连接次数，如果某个插件对应的请求频繁创建新连接，就能直接定位。

2. 查看脚本结束时的连接数量 #

你可以在WordPress的 shutdown 钩子中，实时记录当前的MySQL连接数：

add_action('shutdown', function() {
    global $wpdb;
    // 获取当前MySQL的总连接数
    $connected_threads = $wpdb->get_var("SHOW GLOBAL STATUS LIKE 'Threads_connected'");
    error_log("[DB Debug] Shutdown - Total connected threads: {$connected_threads}");
    
    // 也可以查看当前请求的连接状态
    if (is_object($wpdb->dbh)) {
        $thread_id = mysqli_thread_id($wpdb->dbh);
        error_log("[DB Debug] Shutdown - Current thread ID: {$thread_id}");
    }
});

同时，在服务器上用命令实时监控MySQL连接数：

watch -n 1 "ss -t -a | grep mysql | wc -l"

配合JMeter测试，观察连接数是否在测试期间持续上升，测试结束后是否快速下降——如果测试结束后连接数仍居高不下，说明存在连接泄漏。

三、深层问题的优化方案 #

1. 修复连接复用问题 #

如果排查到插件手动创建连接，优先替换为使用WordPress的$wpdb对象；如果无法修改插件代码，可以禁用该插件，或者用自定义代码拦截它的连接调用，复用全局$wpdb连接。

2. 调整W3 Total Cache配置 #

• 检查缓存命中率：在W3TC的仪表盘查看页面缓存、数据库缓存的命中率，确保关键页面（首页、产品列表页）的命中率超过90%。
• 优化数据库缓存：对于WooCommerce的动态查询（比如库存、价格），可以尝试延长缓存过期时间，或者用W3TC的“高级缓存规则”强制缓存这些查询。
• 启用Opcode缓存：确保PHP的opcache已经开启，减少PHP脚本的编译时间，间接降低请求处理时间，减少连接占用时长。

3. 优化服务器配置 #

• Apache MPM调整：如果用的是Prefork MPM，降低MaxClients（比如设为150），避免过多Apache进程同时打开MySQL连接；优先切换到Event MPM，减少进程数，降低资源占用。
• MySQL连接超时设置：缩短wait_timeout和interactive_timeout到30秒，让MySQL自动关闭闲置连接：

  SET GLOBAL wait_timeout = 30;
  SET GLOBAL interactive_timeout = 30;
  

  然后在my.cnf中永久保存配置。

4. 数据库查询优化 #

• 给WooCommerce的核心表添加索引：比如wp_postmeta表的meta_key和post_id组合索引，wp_woocommerce_product_meta_lookup表的相关字段索引。
• 禁用WooCommerce的实时库存检查：如果业务允许，在WooCommerce设置中关闭“库存减少时通知”，改用定时任务同步库存。

四、临时应急方案（应对大流量） #

如果距离大流量时间紧迫，可以先采取以下措施：

• 启用CDN：把静态资源、缓存页面放到CDN，减少回源请求。
• 静态化关键页面：用WP2Static等工具把首页、产品列表页生成静态HTML，直接由Nginx/Apache提供，完全绕过PHP和MySQL。
• 临时提升max_connections：把MySQL的max_connections临时调到2000，缓解连接压力，但这只是权宜之计，必须配合其他优化。

内容的提问来源于stack exchange，提问作者Vinícius Machado Fabiano