COUNT()是最快速可靠的笛卡尔积探测方式，它强制计算总行数、绕过字段处理干扰、配合EXPLAIN可验证，需结合单表与连接后行数比对，并注意外连接中COUNT()与COUNT(字段)的NULL差异。
直接用 COUNT(*) 查连接结果行数，是最快速、最可靠的笛卡尔积探测方式。 它不依赖业务语义，也不需要预估数据量，只要一行查询就能暴露问题。
为什么 COUNT(*) 比 SELECT * 更适合探测笛卡尔积
执行 SELECT * 看前几行，根本看不出膨胀程度；而 COUNT(*) 强制数据库算出总行数，一旦远超预期（比如两个百行表返回上万行），基本就是笛卡尔积在作祟。
- MySQL 会为
COUNT(*)优化统计路径（尤其 MyISAM 表），但即使 InnoDB，也比全结果集扫描轻得多 - 它绕过了字段别名、NULL 处理、类型转换等干扰项，只聚焦“组合数量”这个本质指标
- 配合
EXPLAIN可交叉验证：如果rows列显示极大值，且Extra出现Using join buffer或空条件，风险极高
实际探测时必须加 WHERE 条件再比对
单独查 COUNT(*) FROM t1 JOIN t2 没意义——你得知道“应该有多少行”。正确做法是分步比对：
- 先查单表行数：
SELECT COUNT(*) FROM orders、SELECT COUNT(*) FROM customers - 再查连接后行数：
SELECT COUNT(*) FROM orders o JOIN customers c ON o.customer_id = c.id - 如果结果接近
orders行数 ×customers行数（比如 1000 × 500 = 500000），但业务上每个订单只对应一个客户，那说明ON条件没生效或写错了
GROUP BY + COUNT(*) 能定位具体哪一端放大
当怀疑某张表是“放大源”（比如中间关联表 user_role），用分组计数能立刻看清分布：
SELECT user_id, COUNT(*) AS role_count FROM user_role GROUP BY user_id ORDER BY role_count DESC LIMIT 5;
如果发现某个 user_id 对应几十甚至上百条 role_id，而业务上一人最多 5 个角色，就说明这张表本身存在脏数据或设计缺陷。这种放大会直接传导到上层 JOIN 结果中。
容易忽略的陷阱：外连接 + 聚合函数的 NULL 干扰
用 LEFT JOIN 时，COUNT(*) 仍会把 NULL 行计入总数，但 COUNT(非空字段) 会跳过右表无匹配的行。例如：
-
SELECT COUNT(*) FROM users u LEFT JOIN profiles p ON u.id = p.user_id→ 返回所有用户数（含无 profile 的用户） -
SELECT COUNT(p.id) FROM users u LEFT JOIN profiles p ON u.id = p.user_id→ 只返回有 profile 的用户数 - 若两者相差极大，说明大量用户缺失 profile，但这不是笛卡尔积；若
COUNT(*)远大于users行数，才是真问题
真正危险的是没加 ON 条件的 JOIN，或者条件列存在大量 NULL 导致索引失效——这时 COUNT(*) 就是第一道防线。
