二度人脉指用户关注的人（一度）所关注的人，且排除自身及一度好友；SQL中通过两次INNER JOIN实现路径查询，并用NOT EXISTS过滤一度好友和拉黑用户，必须配合三类索引保障性能。
什么是二度人脉，SQL里怎么定义这个关系
二度人脉 = 你关注的人（一度）所关注的人，且不是你自己、也不是你的一度好友。它本质是两次 JOIN 的路径查询，不是递归或图遍历——别被“社交图谱”吓住，用标准 SQL 完全能解。
假设表结构简单清晰：follows(user_id, followee_id)，主键为 (user_id, followee_id)，无自关注，无重复边。
- 第一层：找出所有一度好友 →
follows AS f1 WHERE f1.user_id = ? - 第二层：对每个一度好友，查他们关注的人 →
follows AS f2 ON f2.user_id = f1.followee_id - 过滤掉自己（
f2.followee_id != ?）和一度好友（NOT EXISTS (SELECT 1 FROM follows f3 WHERE f3.user_id = ? AND f3.followee_id = f2.followee_id)）
用 INNER JOIN 还是 LEFT JOIN？为什么必须用 INNER
这里必须用 INNER JOIN。二度人脉是“存在路径”的显式结果，不是补全型查询；用 LEFT JOIN 会引入 NULL 行，干扰去重和过滤逻辑，还可能让后续的 NOT EXISTS 判定失效。
常见错误是写成：
SELECT f2.followee_id FROM follows f1 LEFT JOIN follows f2 ON f2.user_id = f1.followee_id WHERE f1.user_id = 123;
这会返回大量 NULL 的 f2.followee_id，实际业务中根本无法识别哪些是有效二度节点。
-
INNER JOIN确保每行都对应一条真实存在的二跳路径 - 如果某一度好友没关注任何人，它自然不出现在结果里——这符合语义，不该强行保留
- 索引有效性依赖
INNER：数据库优化器更容易利用(user_id)和(user_id, followee_id)复合索引
性能瓶颈在哪？三个必须加的索引
没索引时，两层 JOIN 在万级用户下就会秒变秒级响应；十万量级直接超时。关键不是写法，是索引覆盖路径中的全部查找条件。
-
INDEX idx_user_id ON follows(user_id)：加速找一度好友 -
INDEX idx_followee_id ON follows(followee_id)：加速二度去重判断（NOT EXISTS子查询里查「是否为一度」时要用到） -
INDEX idx_user_followee ON follows(user_id, followee_id)：让f2.user_id = f1.followee_id关联走索引嵌套循环（Nested Loop），避免临时表和文件排序
漏掉任意一个，执行计划里大概率出现 Using join buffer (Block Nested Loop) 或 Using temporary; Using filesort —— 这些就是慢的根源。
如何避免重复推荐和已拉黑用户
生产环境不能只查路径，还得叠加业务规则。重复靠 DISTINCT 不够：如果两个一度好友同时关注同一个人，DISTINCT 能去重，但代价是排序开销大；更优解是把去重逻辑下推到 NOT EXISTS 外层。
拉黑需额外表 blocks(blocker_id, blocked_id)，且必须走索引关联：
AND NOT EXISTS ( SELECT 1 FROM blocks b WHERE b.blocker_id = 123 AND b.blocked_id = f2.followee_id )
- 加
INDEX idx_blocker_blocked ON blocks(blocker_id, blocked_id)，否则子查询变成全表扫 - 不要用
LEFT JOIN blocks ... WHERE b.blocked_id IS NULL：空值语义易错，且 MySQL 对LEFT JOIN + IS NULL的优化不如NOT EXISTS - 如果拉黑是双向生效（A拉黑B ⇒ B也看不到A），逻辑要另加判断，不能只查单向
二度人脉看似只是两层 JOIN，真正卡住上线的，往往是索引缺失、空值处理不当、以及把业务过滤硬塞进 JOIN 条件里导致执行计划崩坏。先跑 EXPLAIN，再改 SQL。
