自审日期：2026 年 10 月 15 日。正文：SQL 能执行结果为什么仍可能不对。状态：原稿曾通过；本次按用户意见扩充，待重新审阅。
沿用第一章的读者定位：有少量 SQL 基础，希望理解 AI 查询机制的开发者。本章通过一个金额变化追查关联粒度，再扩展到口径核对。
| 容易卡住的地方 | 已作调整 |
|---|---|
| 查询为什么突然关联明细表 | 从“同时查看商品明细行数”的具体要求开始，让关联有实际用途 |
| 粒度是抽象术语 | 先展开 1002 号发票的两行关联结果，再解释一行代表什么 |
| 明细行数是否就是销售件数 | 明确本题统计行数，避免把两种指标混在一起 |
| 为什么不直接加总明细金额 | 补充本样例可以这样核对，并说明保留发票金额定义的理由 |
| 用 DISTINCT 得到正确数值是否就算修复 | 增加另一张同额发票，实际展示正确 8500 元却漏算成 5500 元 |
| 内容像检查清单或概念堆叠 | 让重复累计案例占据主线，其他口径只作必要延伸，删去结尾的设问式铺垫 |
在 Python 自带 SQLite 3.42.0 中执行：
核对输出：chapter-02-results.json。第一章的客户、发票原始数据与正文保持原样。
2026 年 10 月 15 日，按第一章精简后的风格，删去重复金额解释、过渡句与口径检查表；修正部分只展示 JOIN 和计数表达式的变化，完整 SQL 仍保存在样例文件。新增章末小结，归纳关联基数、指标粒度和业务口径，保留金额 DISTINCT 的反例。
中文字符从 2062 减至 1281，约减少 38%。已检查替换步骤能重建原修正 SQL、结果表与核对输出一致、本地链接及代码块完整。本次未改变样例数据和可运行查询。
2026 年 10 月 15 日，用户同意进入第 3 章，并要求保持当前的精练风格、写完先自审再交审阅。
2026 年 10 月 15 日，用户指出第二章偏薄，要求围绕自由 SQL 的复核、权限处理成本和提示词执行可靠性展开，并补充适用使用者与物理结构暴露带来的负担。
正文引用 PostgreSQL RLS 和 Trino OPA 的官方文档作为数据库与查询层权限的例子，未新增具体产品部署承诺。本次未改变 SQL、数据与原有数值结果；不重复运行原样例。
扩充后约 2200 个中文字。已通读新增段落，将小节题名收紧为“复杂 SQL 的复核和权限处理成本”；与修改前合订稿比较，全部 5 个代码块保持一致。合订稿同步更新本章，其余章节正文保留。
按用户意见，在物理字段暴露段落后加入字段随手命名的自嘲，以“不方便在客户面前念出来的前缀”和“解释当时的精神状态”轻带过去；收尾按用户后续意见改为“大家还是多遵守命名规范，出来混都是要还的，指不定哪天就社死了”。单章与合订稿同步，不新增实际字段或改动样例。
复核日期：2026 年 10 月 15 日。按“关联错误 → 业务口径 → 字段上下文 → 复杂查询成本 → 适用工具和使用者”通读，合并后半章重复的提示词、复核和维护成本解释，收短小结与样例运行说明。命名与“社死”的自嘲段落完整保留。
两处表述进一步收窄：
本次读取以下官方文档正文核对，而非根据检索摘要下结论：
| 资料 | 与本章相关的实践 |
|---|---|
| Databricks Genie 实践建议 | 从少量必要表字段开始，整理元数据，优先使用 SQL 表达式和示例，以基准问题测试，再邀请业务用户验证 |
| Looker Conversational Analytics 实践建议 | 清晰命名和字段说明，收窄分析主题，硬性要求优先进入模型，避免重复指令，使用已验证查询 |
| PostgreSQL RLS | 数据库按角色、策略限制行，不能把应用层 SQL 改写成本推广到所有权限机制 |
| Trino OPA | 查询层按身份和授权策略落实访问控制、行过滤与列掩码 |
结论：与上述官方实践方向一致；这些文档支持数据整理、结构化定义、权限执行和持续校准，不证明某一种架构在所有场景下最优，也不保证结果始终正确。
中文字符从 2307 减至 1997，约精简 13%。未改变 SQL 或数据；已比较全部 5 个代码块、3 张结果表均保持一致，并核对单章与合订稿、本地链接和幽默段落。其余章节正文未改，原样例不重复执行。