必须用 group by 配合 count() 才能获取每个分类的数量，否则聚合函数会将结果压成单行；优先使用 left join + group by 而非相关子查询，以确保包含无产品的分类且性能更优。
子查询里用 COUNT() 必须配 GROUP BY
直接在子查询中写 COUNT(*) 却不加 GROUP BY，数据库会报错或返回单行结果（比如所有分类共几条），根本得不到“每个分类的数量”。这是因为聚合函数默认把整个结果集压成一行，必须明确告诉它按哪个字段分组。
常见错误写法：SELECT name, (SELECT COUNT(*) FROM products WHERE category_id = c.id) FROM categories c——这其实能运行，但属于相关子查询，性能差；而如果写成 SELECT (SELECT COUNT(*) FROM products) FROM categories，就完全没分组逻辑，纯属误用。
- 真正要“每个分类数量”，优先考虑
JOIN + GROUP BY，不是非用子查询 - 若坚持用子查询，得是相关子查询：外层每扫一条分类，内层算一次对应产品的数量
- MySQL 8.0+、PostgreSQL 支持在
SELECT子句里直接放聚合子查询，但 SQLite 不支持
用 LEFT JOIN 配合 GROUP BY 更稳更快
比起嵌套子查询，LEFT JOIN 能一次拉出所有分类和它们的产品数，包括那些没有产品的分类（数量为 0）。子查询方式默认丢掉空分类，除非你额外补 COALESCE 和 UNION，徒增复杂度。
实操示例：
SELECT c.name, COUNT(p.id) AS product_count FROM categories c LEFT JOIN products p ON c.id = p.category_id GROUP BY c.id, c.name;
-
COUNT(p.id)统计非 NULL 的产品 ID，自动跳过无匹配的分类行（LEFT JOIN后p.id为 NULL） - 务必在
GROUP BY中包含c.id，否则 PostgreSQL 会报错，MySQL 在严格模式下也会 - 别用
COUNT(*)，它会把 NULL 行也当一行计，导致空分类显示为 1
相关子查询写法及性能隐患
如果业务强制要求用子查询（比如报表工具只允许单层 SELECT），那就得用相关子查询。语法上没问题，但执行时数据库会对每条外层记录重复执行一次内层查询，数据量一大就明显变慢。
正确写法：
SELECT c.name, (SELECT COUNT(*) FROM products p WHERE p.category_id = c.id) AS product_count FROM categories c;
- 子查询里的
WHERE条件必须关联外层表，如p.category_id = c.id - 确保
products.category_id有索引，否则每次子查询都是全表扫描 - MySQL 5.7 默认可能不走索引，建议升级到 8.0 或显式加
FORCE INDEX
NULL 分类和空字符串分类容易被漏统计
实际数据里常有 category_id IS NULL 或 category_name = '' 的脏数据。用 JOIN 时这些记录不会出现在结果里；用相关子查询时，它们会被归到“找不到分类”的情况，数量为 0，但不会单独列出来。
- 若需统计 NULL 分类，得单独加一句：
SELECT 'Uncategorized', COUNT(*) FROM products WHERE category_id IS NULL - 空字符串分类建议先清洗：
UPDATE products SET category_id = NULL WHERE category_id = '' - 别依赖子查询自动覆盖边界情况——它只响应你写的条件，不会替你猜业务含义
