优化慢查询/子查询性能：现有子查询耗时15秒求改进方案

嘿，你这个情况挺典型的——明明表数据量不大（8200行），查询却跑15秒，还排除了表关联的问题，那大概率是子查询逻辑或者索引缺失导致的。我给你几个实用的优化思路：

1. 先补个关键索引，这是最立竿见影的 #

你要按「用户ID+状态」来筛选和关联，现在的表估计没建对应的复合索引，导致每次查询都要全表扫描。直接建个复合索引：

CREATE INDEX idx_sub_user_status ON jos_payplans_subscription(user_id, status);

这个索引能让数据库快速定位到某个用户的所有订阅状态，不管是找非活跃记录，还是检查有没有活跃记录，都不用扫全表了。

2. 重写查询逻辑，换掉低效的子查询 #

你的需求是「找到所有只有非活跃订阅（status=1603）的用户」，原查询可能用了NOT EXISTS或者NOT IN的子查询，这种写法在没有索引的时候效率极低。推荐两种更高效的写法：

写法一：用分组聚合筛选用户 #

先通过分组统计每个用户的活跃/非活跃订阅数量，直接筛选出符合条件的用户ID，再关联用户表：

SELECT c.id, c.name, c.username, c.email
FROM jos_users c
JOIN (
    SELECT user_id
    FROM jos_payplans_subscription
    GROUP BY user_id
    -- 确保该用户没有任何活跃订阅（这里假设活跃状态是不等于1603，你可以改成具体的活跃值）
    HAVING SUM(CASE WHEN status != 1603 THEN 1 ELSE 0 END) = 0
    -- 同时确保该用户至少有一个非活跃订阅
    AND SUM(CASE WHEN status = 1603 THEN 1 ELSE 0 END) > 0
) s ON c.id = s.user_id

写法二：用LEFT JOIN+NULL判断替代NOT EXISTS #

这种写法也是数据库优化器比较容易处理的，避免子查询的嵌套开销：

SELECT DISTINCT c.id, c.name, c.username, c.email
FROM jos_payplans_subscription s
JOIN jos_users c ON s.user_id = c.id
-- 左连接该用户的活跃订阅记录
LEFT JOIN jos_payplans_subscription s_active 
    ON s.user_id = s_active.user_id 
    AND s_active.status != 1603 -- 这里替换成你实际的活跃状态值
WHERE s.status = 1603
-- 说明该用户没有活跃订阅
AND s_active.user_id IS NULL

这里用DISTINCT是防止用户有多个非活跃订阅时重复输出结果，也可以用GROUP BY代替。

3. 用EXPLAIN排查瓶颈 #

不管用哪种写法，都可以在查询前加EXPLAIN，比如：

EXPLAIN SELECT c.id, c.name, c.username, c.email ...

看执行计划里的这几个关键列：

• type：如果是ALL说明是全表扫描，要优化；如果是ref或range就说明用到索引了
• key：显示实际用到的索引，要是为空就说明没用上索引，得检查索引建对了没
• rows：预计扫描的行数，要是接近8200就说明没用到索引

4. 小细节优化 #

• 别用SELECT *，就像你现在这样只取需要的字段（id、name、username、email），减少数据传输和处理的开销
• 如果jos_users表数据量也不小，记得确认jos_users.id的主键索引存在（一般主键默认会有，但检查下没毛病）

按这个思路改完，你的查询应该能从15秒降到毫秒级了。

内容的提问来源于stack exchange，提问作者Dyvel