先说清要不要保留零记录对象
请 ChatGPT 写 SQL 计数查询时，除了表结构与条件，还要说明没有符合记录的对象是否保留。本例要求列出全部用户及其完成订单数，因此没有订单的丙也必须出现在结果中，数量为0。
数据与SQL由本站自拟，参考查询在2026年10月13日使用本地SQLite 3.43.2执行核对，不是ChatGPT实测或生产数据验证。其他数据库的语法与行为需按实际文档重新检查。
给两张表与预期结果
customers包含id与name，id为主键，记录为1甲、2乙、3丙。orders包含非空主键id、customer_id与status：101属甲且completed；102属甲且cancelled；103、104属乙且completed；丙没有订单。
目标只计status等于completed的订单，按用户ID排序。人工参考结果是甲1、乙2、丙0；不是计算订单金额，也不是把所有状态都计入。
主键说明不能省略。本文用COUNT(o.id)计数，是因为订单id在实际订单记录里非空；如果换成可为空字段，计数含义就可能不同。
一条本地核对过的参考查询
SELECT c.id,c.name,COUNT(o.id) AS completed_count FROM customers AS c LEFT JOIN orders AS o ON c.id=o.customer_id AND o.status='completed' GROUP BY c.id,c.name ORDER BY c.id;
这里保留customers作为左侧对象，把订单状态条件放进连接ON。没有符合订单的用户仍有结果位置，o.id为NULL时COUNT(o.id)不增加数量，所以丙得到0。
本文的计数单位是一条订单记录。若后来连接其他一对多表导致同一订单重复出现，应重新核对结果行的粒度，不能直接沿用这个简单例子的数量结论。
为什么不要随意把条件搬到WHERE
在本例中，把状态条件从ON移到WHERE o.status='completed'，会在连接后排除没有对应订单的丙。本地对照结果只留下甲1、乙2，没有丙这一行。
这不是WHERE永远不能与LEFT JOIN一起用。比如筛选用户本身的条件可能正是需求；关键是当前条件在哪个阶段过滤哪类行，以及有没有保留零订单用户的要求。
如果模型生成另一个写法，让它解释丙会怎样进入输出，并在同样样例上运行；不要仅从语法关键词判断查询一定正确。
COUNT(*)为什么会在这里误计
在保留全部用户的参考查询里，把COUNT(o.id)改成COUNT(*)，会计入丙的那条补NULL结果行，本地对照中丙显示1，不符合“完成订单为0”的定义。
COUNT(*)统计结果行数量，COUNT(o.id)统计该字段非NULL的次数。区别要结合当前连接结果理解，不是所有统计都应该替换成COUNT(id)。
如果id不是非空订单主键，或你要统计的是另一种对象，就必须重新说明口径。不要把这份示例当成普遍计数模板。
用能暴露错误的小样本验收
至少保留三类对象：有符合订单、有不符合状态订单、完全没有订单。本例甲同时有completed和cancelled，能检查状态过滤；乙有两条completed，能检查多条计数；丙没有订单，能检查保留与0值。
检查输出是否正好3行、ID顺序是否1/2/3、数量是否1/2/0。只验证一个有订单的用户，可能看不出WHERE漏行或COUNT(*)误计。
放到真实数据库前再确认环境
提供真实表名与字段约束的去敏描述，不分享连接口令。先在测试数据上运行只读SELECT，再确认目标数据库、权限、字段类型与业务口径；本文不要求执行修改表或删除数据的语句。
结果不对时，附上小样本、期望结果和实际结果再追问。SQL能执行只是起点，是否回答了“全部用户的完成订单数”还需要核对。