1. 从一次读书笔记卡壳说起哈希连接到底访问了几次表我在整理 Oracle 读书笔记时卡在一个很具体的问题上哈希连接Hash Join里驱动表和被驱动表到底各访问几次书上写的是「0 次或 1 次」但光看结论记不住过两天就忘。真正让我记住的是把执行计划里的 Starts、A-Rows、Buffers 这几列对着实验数据一行行读下来。这篇笔记复盘的就是这个过程先用三组 SQL 实验把哈希连接的表访问次数验证清楚再把整理好的笔记通过 TaoToken 统一 Key/API 通道接进 AI 工具让后续检索和追问不用反复翻文档。如果你也在做 Oracle 执行计划相关的读书笔记或者想把技术笔记接进 AI 助手做长期检索这套流程可以直接跟做。核心检索词先摆出来Oracle 哈希连接是什么它是优化器在大表关联时常用的一种连接方式把较小的行源在内存里建成哈希表再用另一侧的行去探测匹配。适合谁适合正在读 Oracle 优化类书籍、需要把执行计划读透的开发和 DBA。能做什么能让你从「背结论」变成「看数据说话」。我试过把执行计划截图丢给 AI 让它解释结果它把 Starts 和 A-Rows 混着讲越看越乱。后来改成先把实验数据整理成结构化笔记再通过统一通道喂给模型追问质量明显不一样。下面按「实验验证 → 配置接入 → 验证请求 → 排错」的顺序展开。2. 哈希连接执行计划精读三组实验的数据对照2.1 基线实验两侧各访问 1 次先看最基础的关联查询用 leading 和 use_hash 提示固定执行路径SELECT /*leading(t1) use_hash(t2)*/ * FROM t1, t2 WHERE t1.id t2.id;执行计划里关键几行是这样的IdOperationNameStartsE-RowsA-RowsBuffersUsed-Mem0SELECT STATEMENT110010181HASH JOIN110010010181235K2TABLE ACCESS FULLT1110010073TABLE ACCESS FULLT21118K100K1011读法要点Starts 列表示该操作实际执行了几次。这里 T1 和 T2 的 Starts 都是 1说明两侧各被访问一次。Buffers 列能看出代价分布——T2 扫了 1011 个块T1 只有 7 个块因为 T1 是小表被选作驱动侧建哈希表T2 作为探测侧。Used-Mem 显示哈希表实际用了约 1235K 内存。注意E-Rows 是优化器估算行数A-Rows 是实际返回行数。两者差距大时往往意味着统计信息需要更新这会直接影响连接方式的选择。2.2 实验一驱动侧过滤后归零被驱动侧访问 0 次给驱动表 T1 加一个几乎不可能命中的过滤条件SELECT /*leading(t1) use_hash(t2)*/ * FROM t1, t2 WHERE t1.id t2.id AND t1.n 999999999;执行计划变化很关键IdOperationNameStartsE-RowsA-RowsBuffers1HASH JOIN11072TABLE ACCESS FULLT111073TABLE ACCESS FULLT20118K00T1 的 Starts 是 1但 A-Rows 是 0——它被访问了一次只是没返回任何行。T2 的 Starts 直接是 0Buffers 也是 0说明被驱动表根本没被碰。这就是「0 次或 1 次」里 0 次的来源驱动侧建出的哈希表为空探测侧就没有必要执行。2.3 实验二恒假条件让整个哈希连接不执行再加一组更极端的用恒假条件 12SELECT /*leading(t1) use_hash(t2)*/ * FROM t1, t2 WHERE t1.id t2.id AND 1 2;执行计划里多了一层 FILTERIdOperationNameStartsE-RowsA-Rows1FILTER102HASH JOIN010003TABLE ACCESS FULLT1010004TABLE ACCESS FULLT20118K0注意 HASH JOIN 这一行的 Starts 是 0两张表的 Starts 也都是 0。Predicate Information 里 FILTER 的条件是NULL IS NOT NULL优化器在运行时直接短路整个哈希连接一次都没执行。这组数据把「0 次」的含义补全了不只是被驱动表可能 0 次整个连接操作本身都可能 0 次。2.4 把三组数据整理成可检索的笔记结构三组实验对照下来结论就清晰了哈希连接中驱动表和被驱动表的访问次数只可能是 0 或 1不存在嵌套循环那种被驱动表反复扫描的情况。我把每组实验整理成固定字段SQL 文本、提示、Starts、A-Rows、Buffers、结论一句话。这种结构化笔记特别适合后续接进 AI 做检索因为字段固定模型容易对齐。3. TaoToken 前置准备统一 Key 与通道配置笔记整理好之后下一步是把它接进 AI 工具做长期检索和追问。这里用 TaoToken 做统一 Key/API 通道好处是多个工具共用一套凭证不用每个客户端单独配。先到控制台创建 API Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite创建完 Key 之后接入文档在这里不同客户端的配置方式都有说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteAPI 基础地址统一用https://taotoken.net/api如果你主要做长期编码和 Agent 类任务可以看 Coding Plan 的说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewriteKey 管理页面在这里方便后续轮换和排查https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite注意Key 只创建一次就够多个客户端共用。不要把 Key 写进会提交到代码仓库的文件里用环境变量或本地配置文件承载。4. 可复制的 settings.json 配置骨架下面这份配置骨架可以直接改 Key 后使用。以常见的 AI 编码工具配置为例把模型通道指向 TaoToken 的统一地址{ provider: taotoken, apiKey: sk-替换成你在控制台创建的Key, baseUrl: https://taotoken.net/api, model: claude-sonnet-4-20250514, maxTokens: 8192, temperature: 0.3, timeout: 60000, retry: { enabled: true, maxAttempts: 3, backoffMs: 1000 }, context: { notesDir: ./oracle-notes, includePatterns: [*.md, *.sql], maxContextFiles: 20 } }几个参数说明一下。temperature 设 0.3 是因为技术笔记检索需要稳定输出不需要太多发散。maxContextFiles 控制在 20 以内避免一次塞太多文件把上下文撑爆。retry 部分建议保留网络抖动时自动重试比手动重跑省事。如果你用的是 Claude Code 这类工具配置入口和字段名可能略有差异参考接入文档里的对应章节调整即可https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite配置写好后把 Oracle 笔记目录指向 notesDir模型就能在追问时引用你整理好的实验数据而不是凭空编执行计划。5. 验证请求确认通道打通并能检索笔记配置完成后先做一次最小验证确认通道可用。用 curl 发一个简单请求curl -X POST https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-替换成你的Key \ -H anthropic-version: 2023-06-01 \ -d { model: claude-sonnet-4-20250514, max_tokens: 256, messages: [ {role: user, content: 用一句话说明 Oracle 哈希连接中驱动表的访问次数范围} ] }预期返回里应该包含类似「0 次或 1 次」的表述。如果返回正常说明 Key 和通道都没问题。接着做笔记检索验证。在 AI 工具里提问根据我整理的 oracle-notes 目录实验一中 T2 表的 Starts 和 Buffers 分别是多少为什么如果配置正确模型应该能引用你笔记里的具体数值Starts0Buffers0并解释是因为驱动侧哈希表为空导致探测侧未执行。这一步能验证两件事通道通了笔记也确实被检索到了。想直接在对话里验证模型对哈希连接的理解可以用模型对话入口https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite6. 本篇常见错排查6.1 请求返回 401 或鉴权失败最常见的原因是 Key 复制时带了空格或者请求头字段名写错。Anthropic 风格用x-api-keyOpenAI 风格用Authorization: Bearer两者不要混用。先到 Key 管理页确认 Key 状态正常https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite6.2 模型答非所问没引用笔记先检查 notesDir 路径是不是相对路径写错了。相对路径是相对于工具的工作目录不是配置文件所在目录。建议先用绝对路径验证一次确认能检索到再改回相对路径。另外 includePatterns 如果只写了*.mdSQL 文件不会被纳入实验数据就检索不到。6.3 执行计划数据对不上如果你复现实验时 Starts 和笔记里不一致先确认统计信息是否更新过。动态采样dynamic sampling在不同数据量下可能给出不同的估算进而影响连接顺序。可以在 SQL 里加/*dynamic_sampling(0)*/排除干扰或者先收集统计信息再跑。6.4 上下文超限报错maxContextFiles 设太大或者笔记文件单个过大都会触发上下文超限。把大文件拆成按实验分节的小文件每个文件控制在几百行以内。哈希连接这类实验笔记按「基线 / 实验一 / 实验二」拆成三个文件就很好检索。6.5 连接超时timeout 默认 60000 毫秒如果笔记量大、检索慢可以适当调大。但更根本的优化是减少单次检索的文件数用更精确的提问缩小范围而不是靠加大超时硬扛。7. 把笔记接进长期工作流哈希连接这三组实验的价值不在于记住「0 次或 1 次」这个结论而在于你亲手对着 Starts、A-Rows、Buffers 读了一遍数据。笔记整理成结构化字段后接进 TaoToken 统一通道后续遇到执行计划相关的疑问直接追问就能调出当时的实验数据不用再翻书翻截图。长期做 Oracle 优化笔记的话建议把 Coding Plan 也用上Agent 类任务和编码场景共用一套 Key省去反复切换配置的麻烦https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite配置骨架里的 retry 和 context 两段是我踩过坑之后加上的——前者应对网络抖动后者控制检索范围。你可以先按默认值跑通再根据自己的笔记规模微调。