mysql 8.0+/postgresql严格模式下，group by后必须包含所有非聚合列或对其使用聚合函数，否则报错；join后count易因行复制失真，应优先用distinct或子查询；count(*)最快，count(col)在null多时可能全表扫描；where过滤行，having过滤分组结果。
GROUP BY 后漏掉非聚合列就报错
MySQL 8.0+、PostgreSQL 等严格模式下，SELECT name, COUNT(*) FROM users GROUP BY city 直接报错：column "name" must appear in the GROUP BY clause or be used in an aggregate function。这不是语法错误，而是语义模糊——数据库不知道你想要哪个 name。
- 真要取每个城市的任意一个名字，用
MAX(name)或MIN(name)，它们不保证是“第一条”，但稳定、快、可索引 - 想拿分组内某条完整记录（比如最新订单的全部字段），别硬塞进
GROUP BY，改用窗口函数如ROW_NUMBER() OVER (PARTITION BY city ORDER BY created_at DESC)再过滤 - MySQL 5.7 默认允许隐式分组（
sql_mode缺失ONLY_FULL_GROUP_BY），但一迁到新库或开启严格模式就崩，别依赖它
JOIN 后 COUNT/SUM 被悄悄放大
一对多 JOIN（如部门 ↔ 员工）会让主表行被复制，COUNT(e.id) 统计的是关联后组合行数，不是部门下的真实员工数；更糟的是，如果再连第三张表（如项目），可能触发笛卡尔积膨胀。
- 查“每个部门员工数和项目数”，不能直接三表
LEFT JOIN后COUNT——COUNT(e.id)和COUNT(p.id)都会变成员工数 × 项目数 - 正确做法：用子查询或 CTE 分别聚合，再
JOIN汇总，或者用COALESCE(COUNT(DISTINCT e.id), 0)+COALESCE(COUNT(DISTINCT p.id), 0) -
LEFT JOIN下COUNT(*)和COUNT(e.id)行为不同：COUNT(*)算的是结果集行数（含空员工的部门也计 1），COUNT(e.id)只统计非 NULL 的员工 ID（空部门得 0）
COUNT(col) 在 NULL 多时拖慢查询
COUNT(*) 通常走索引或元数据，最快；COUNT(col) 只统计非 NULL 值，但如果该列 NULL 比例高、又没非空约束，优化器可能放弃索引，退化成全表扫描。
Prompt Log
下载
从 AI 编程会话日志（Clawdbot、Claude Code、Codex）中提取对话记录。该功能用于在用户要求导出提示词历史、会话日志或 `.jsonl` 格式的会话文件时使用。
- 统计总行数，无条件用
COUNT(*)，别写COUNT(1)或COUNT(id)—— 后两者在某些旧版 MySQL 有额外开销，且语义不如*清晰 - 统计某字段非空值数量，确认该列建了覆盖索引（索引包含该列且定义为
NOT NULL），否则性能风险大 - 业务上需要把 NULL 当 0 参与求和？用
SUM(COALESCE(amount, 0))，别依赖SUM()自动忽略——有时你就是要感知缺失
HAVING 误当 WHERE 用，或反过来
WHERE 过滤原始行，HAVING 过滤分组后结果。放错位置，结果可能碰巧对，但逻辑错、性能差。
- 查“订单总额超 1 万的城市”，必须
WHERE status = 'paid'提前筛行，再GROUP BY city，最后HAVING SUM(amount) > 10000—— 早筛省资源 -
WHERE SUM(amount) > 10000是语法错误，聚合函数不能出现在WHERE - 想筛“平均薪资 > 8000 的部门”，必须用
HAVING AVG(salary) > 8000；若写成WHERE salary > 8000，就变成“只统计高薪员工”，平均值被人为拉高
真正麻烦的不是报错，而是结果看起来合理却埋着逻辑漏洞：JOIN 膨胀、NULL 被静默丢弃、分组字段遗漏却靠兼容模式糊弄过去。上线前用小数据集手工验算几条关键分组，比调优执行计划更管用。
