WHMCS 系统卡顿、CPU 飙高的核心原因在于对 tblcarts 表的查询引发了严重的全表扫描（Full Table Scan）。
核心问题分析
-
扫描行数巨大（Rows_examined: 812754）： 每次执行该查询，MySQL 都要扫描高达 81.2 万行 数据，而最终只返回 1 行（
Rows_sent: 1）。高频的高并发扫描会瞬间耗尽 CPU 资源。 -
BINARY关键字导致索引失效： 查询语句中使用了where BINARY tag = '...'。在 MySQL 中，对字段施加BINARY函数或操作符会强制进行区分大小写的二进制字节比对。这会导致该字段上原有的常规索引完全失效，迫使 MySQL 转向全表扫描。 -
数据表严重虚胖：
tblcarts是临时购物车表。积压了 81 万多条记录，说明系统中存在大量历史遗留的、未成单的游客购物车死数据，且没有被正常清理。
解决方案
请按照以下步骤依次排查和优化，通常完成前两步即可让 CPU 降下来。
第一步：清理临时表垃圾数据（见效最快）
81 万行的购物车数据绝大多数都是无用的垃圾数据。清理该表可以瞬间将扫描行数从 81 万降到极低。
-
查看所有数据库名称（如果你不记得名字了）：
SHOW DATABASES; -
选择数据库（假设你的数据库名是
whmcs_db，请替换为实际名称）：USE whmcs_db;
-
方法 A：直接全量清空（推荐在深夜低峰期执行） 注意：这会导致当前正在网站上加入购物车但还未下单的用户购物车被清空。
TRUNCATE TABLE tblcarts; -
方法 B：条件清理（保留近期数据） 先观察一下
tblcarts表的结构，看看有哪些时间字段（比如date,last_active,updated_at等）：DESC tblcarts;如果存在时间字段，可以删除 30 天以前的无用数据（假设字段名为
last_active）：DELETE FROM tblcarts WHERE last_active < DATE_SUB(NOW(), INTERVAL 30 DAY); -- 清理后释放表空间 OPTIMIZE TABLE tblcarts;
第二步：针对 BINARY 建立高效索引（治本）
由于该 SQL 查询是由 WHMCS 或第三方插件加密代码生成的，你无法直接修改 PHP 源码去掉 BINARY。因此，我们需要在数据库层面让 BINARY 能够走索引。
选项 1：如果你的 MySQL 版本是 8.0+
MySQL 8.0 支持函数索引（Functional Index）。你可以直接针对 BINARY tag 这个表达式建立索引，完美契合该查询：
ALTER TABLE tblcarts ADD INDEX idx_binary_tag ((BINARY `tag`));选项 2：如果你的 MySQL 版本是 5.7 或 MariaDB
老版本 MySQL 不支持直接建函数索引。你可以将 tag 字段的排序规则（Collation）直接改为二进制区分大小写的类型（如 utf8mb4_bin），然后建立常规索引：
-- 1. 修改该字段的排序规则为 bin (请先备份数据库！)
ALTER TABLE tblcarts MODIFY COLUMN `tag` VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;-- 2. 补上常规索引
ALTER TABLE tblcarts ADD INDEX idx_tag (`tag`);第三步：检查 WHMCS 定时任务（Cron Job）
标准 WHMCS 会通过每日的 Cron Job 自动清理过期的购物车数据。tblcarts 能堆积到 81 万行，通常意味着两点：
-
Cron 任务异常：请登录 WHMCS 后台，查看
System Logs->Cron Job Log，确认每天的自动化任务是否有正常执行。 -
第三方插件作祟：原生 WHMCS 的
tblcarts表默认并没有tag这个字段。这个查询大概率是由第三方购物车跟踪插件、防丢单召回插件、或魔改的主题模板引入的。如果清理后数据依然几天内暴涨，建议排查并联系该插件开发者优化其清理机制。