查询 · XB 现场笔记

InnoDB 覆盖索引包含查询所需的列

Fri, 03 Mar 2028 00:00:00 +0000

覆盖索引包含某条查询求值和返回结果所需的列。在 InnoDB 中，二级索引记录还会携带主键列，因此即使二级索引定义没有再次列出主键，某条查询也可能已经被覆盖。覆盖描述的是一条具体查询与某个索引之间的关系，不是给索引贴上标签之后，整张表的所有查询都自动获得同样行为。

坏掉的样子

增加返回列可能使覆盖失效。原本能提供标识和时间戳的索引，不一定包含应用后来开始读取的大载荷。优化器仍然可能沿用这个索引定位匹配记录，再访问聚簇记录取得缺失字段。因此，“用到了索引”和“由索引覆盖查询”是两件不同的事，不能从计划中出现索引名字就直接推导后者。

覆盖也不保证访问范围足够小。一个扫描大量条目的查询，可以完全被索引覆盖，仍然花费很多工作。列顺序、过滤条件、排序要求和行数估计都很重要。不要把 Using index 覆盖标记当作查询很快的证明，也不要把它与 Using index condition 索引条件下推标记混淆；后者描述部分条件在索引层求值，并不证明整个返回投影都在索引里。

InnoDB 的可见性检查还会限制通常所说的“只读索引”解释。二级记录不包含与聚簇记录相同的隐藏事务元数据。遇到删除标记条目，或被更新事务修改过的二级索引页时，可能仍需访问聚簇记录才能获得正确可见版本。因此，在并发多版本活动下，一个覆盖计划并不普遍保证聚簇访问次数永远为零。

快速验证

历史示例保持原样，当前没有 MySQL 8.4，因此本次没有重跑；计划结果仍属于既有运行记录。

准备一台新的 MySQL 8.4 实例，使用能够创建测试模式的客户端会话。既有运行记录中的版本是 MySQL 8.4.11。确认实验模式名尚未使用，遇到非预期 SQL 错误就停止，并保持同一个会话，以保留当前选中的数据库。下面建立一万行数据，其中一百笔已付款订单，并让载荷列明显比索引所需字段更宽：

CREATE DATABASE xbcatm_index_lab;
USE xbcatm_index_lab;
CREATE TABLE orders (
 id INT PRIMARY KEY,
 status VARCHAR(10) NOT NULL,
 created_at DATETIME NOT NULL,
 payload VARCHAR(1000) NOT NULL,
 INDEX by_status_created (status,created_at)
) ENGINE=InnoDB;
INSERT INTO orders
WITH digits(n) AS (
 SELECT 0 UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3
 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6
 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9
)
SELECT number+1,IF(MOD(number+1,100)=0,'paid','open'),
 TIMESTAMP '2026-01-01 00:00:00' + INTERVAL (number+1) SECOND,
 REPEAT('x',640)
FROM (SELECT a.n+10*b.n+100*c.n+1000*d.n AS number
 FROM digits a CROSS JOIN digits b CROSS JOIN digits c CROSS JOIN digits d) AS numbered;
ANALYZE TABLE orders;
SELECT COUNT(*),SUM(status='paid') FROM orders;

最后的两个计数应为一万与一百。二级索引明确包含状态与创建时间，InnoDB 隐式提供主键标识。先检查并运行只需要这些值的查询：

EXPLAIN SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
SELECT id,created_at FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

既有表格计划给出所建索引及覆盖访问标记，实际分析计划显示覆盖索引查找并返回二十行。结果标识依次为一百、二百，直到两千，按照时间戳与标识排序。这是在已经填充数据的表上核对过的实际结果，不是从一个空模式推测查询会采用什么访问路径。

接着，把载荷也加入返回列：

EXPLAIN SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;
EXPLAIN ANALYZE SELECT id,created_at,payload FROM orders WHERE status='paid' ORDER BY created_at,id LIMIT 20;

既有计划仍使用同一个索引，却不再具有覆盖标记；实际分析也变成没有覆盖限定的索引查找。这保持了过滤、排序和索引不变，只改变所需返回列，因而能够明确观察投影变化的影响。实际分析命令会真正执行查询，对真实的大查询使用它时，应把这次诊断本身的执行代价算进去。

最后删除本次实验自己创建的模式：

DROP DATABASE xbcatm_index_lab;

这个小型热缓存实验的时间不能当成吞吐量或延迟基准。调度、缓存和测量本身的开销，可能超过两次二十行查询之间的差别。这里验证的是访问形态与结果内容，而不是承诺物理输入输出减少某个固定比例，更不能据此保证生产请求的高分位延迟必然下降一半。

有意识地承担覆盖成本

给二级索引追加字段会占用存储与缓冲池容量，并在相关索引值变化时增加维护工作。较长的主键也会扩大二级索引条目。应覆盖重要而窄的查询，不要默认把大载荷复制到每个索引里。明确列出返回字段，也有助于后续应用变更在审阅时暴露新的数据访问要求，避免一个查询投影变化悄悄改变成本。

保留新增索引之前，应比较代表性的计划、检查行数、前台延迟以及写入代价。使用真实选择率和并发活动进行验证；安静夹具并没有测量可见性检查需要聚簇访问的频率，也没有测量副本维护这些索引的成本。索引应当通过它实际服务的工作负载证明价值，而不是仅因为一次解释输出里出现了期望的标签。

来源

MySQL 8.4 聚簇索引与二级索引，二级记录携带主键列的机制，已核验 2026-09-12。
MySQL 8.4 EXPLAIN 输出，索引使用与覆盖计划标记，已核验 2026-09-12。
MySQL 8.4 InnoDB 多版本机制，二级索引可见性检查需要聚簇访问的条件，已核验 2026-09-12。

分区裁剪跳过查询不可能用到的整张分区

Sun, 13 Feb 2028 00:00:00 +0000

分区裁剪排除的是整张不可能包含匹配行的分区。它与在剩余分区内部利用索引寻找行不同，也不是按页工作的缓存技巧。PostgreSQL 可以在查询规划阶段完成排除，也可以等参数值在执行过程中可用后再裁剪。要判断它是否生效，需要查看实际访问的分区，而不是只看最终返回了多少行。

证明哪些分区不可能命中

声明式分区的边界来自分区键。把日期键限制在十月，可以证明九月和十一月与查询无关。裁剪依赖这些边界，而不是估计其他分区“可能很少匹配”。统计信息仍影响其他规划决策，但行数估计不准，不会让分区归属变成概率判断；这两个层面的信息应分开解释。

裁剪不要求先建索引。排除无关分区后，如果剩余分区的大部分行都需要读取，PostgreSQL 完全可能选择顺序扫描。所以，出现 Index Scan 并不是裁剪成功的判据。应先检查物理关系名和计划结构，再单独评价剩余每张表内部的访问方式。顺序扫描一张相关分区，仍然可能已经省掉其他分区的大量工作。

条件必须能对应分区键及其比较语义。把日期列转换成文本，可能隐藏直接的边界关系，即使某个字符串条件恰好仍选出相同行。应使用有类型的参数和直接表达目标区间的条件，不能假定分区键外面套任意表达式都保留裁剪能力，甚至不能默认它保留原来的日期语义。

参数也能在执行时触发裁剪

常量可以支持规划期裁剪，使计划只留下相关子表。预备语句的通用计划无法提前知道未来每次传入的参数值，但这不表示它必须扫描全部分区：执行初始化时已经知道的值，也可以用于执行期裁剪。看见通用计划中原本存在多个分支，还不足以判断最终都会读取。

EXPLAIN ANALYZE 用 Subplans Removed 报告初始化阶段排除的分区。另一些情况，例如嵌套循环内侧参数在执行期间变化，可以在实际执行过程中继续裁剪。分析这些场景时，需要查看循环次数和子计划是否运行。某个节点显示从未执行，也可能是外层没有输入等其他原因，不能脱离完整计划单独当成裁剪证据。

因此，不能把这些规则简化成“只要不是常量表达式，就会失去裁剪”。参数何时可用，以及表达式是否受支持，共同决定何时能够排除分区。定制计划和通用计划可能不同，但返回同样答案。尤其要注意，同一个通用计划参数可以支持运行时分区裁剪，却不满足部分索引在规划期要求的谓词证明。这两种优化使用的信息时点不同，不能把一个实验的限制直接套到另一个机制上。真正值得确认的是：负载使用真实参数时，哪些分区实际被访问了。

坏掉的样子

只过滤无关字段，可能让所有分区仍然相关；把键转换成无法对应边界的表达式，也可能产生同样结果。调整分区布局前，应检查准确条件和 enable_partition_pruning 设置。手工添加相互矛盾的 CHECK 约束并不是修复方法；普通本地声明式分区会执行自己的边界规则，而基于 CHECK 的约束排除是另一种优化机制。

裁剪也不保证没有锁或规划成本可以忽略。执行初始化阶段排除的分区，在执行开始时仍然会被锁定。大型分区层级可能消耗规划时间和会话内的元数据内存，即使最后只扫描少数子表。应根据真实查询和维护模式选择层级，而不是追求尽可能多的分区数量。

最后，即使裁掉两个分区，第三个分区内部仍可能有几千条无关行。合适的局部索引可能帮助第二阶段。最终返回一百行，不证明只检查了一百行；缓冲命中也不等于物理磁盘读取。必须沿着计划节点看清扫描、过滤与输出之间的区别。

快速验证

把下面内容保存为 partition-pruning.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f partition-pruning.sql。脚本在事务内启用裁剪，并用通用预备计划展示初始化阶段的行为。临时分区上没有建立任何索引。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL datestyle='ISO, YMD';
SET LOCAL enable_partition_pruning=on;
CREATE TEMP TABLE observations (day date,id integer) PARTITION BY RANGE(day);
CREATE TEMP TABLE obs_sep PARTITION OF observations FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
CREATE TEMP TABLE obs_oct PARTITION OF observations FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');
CREATE TEMP TABLE obs_nov PARTITION OF observations FOR VALUES FROM ('2026-11-01') TO ('2026-12-01');
INSERT INTO observations SELECT DATE '2026-09-01'+g%90,g FROM generate_series(0,8999) AS g;
ANALYZE observations;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT count(*) FROM observations WHERE day>=DATE '2026-10-01' AND day<DATE '2026-11-01';
SET LOCAL plan_cache_mode=force_generic_plan;
PREPARE by_day(date) AS SELECT count(*) FROM observations WHERE day=$1;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) EXECUTE by_day(DATE '2026-10-10');
EXECUTE by_day(DATE '2026-10-10');
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT count(*) FROM observations WHERE day::text='2026-10-10';
DO $$ BEGIN
 IF (SELECT count(*) FROM observations WHERE day=DATE '2026-10-10') <> 100 OR
 (SELECT count(*) FROM observations WHERE day>=DATE '2026-10-01' AND day<DATE '2026-11-01') <> 3100 THEN
 RAISE EXCEPTION 'unexpected pruned result';
 END IF;
END $$;
DEALLOCATE by_day;
ROLLBACK;

本轮 PostgreSQL 18.6 单用户 SQL 重跑只扫描 obs_oct，读取十月的三千一百条匹配行。未测试 psql 传输或并发分区锁。通用日期查询报告 Subplans Removed 为二，返回一百行，但仍需在十月分区中过滤三千条其他记录。这同时展示了成功排除无关分区，以及相关分区内部尚未消除的工作量。

文本转换条件扫描三个子表，在明确指定 ISO DateStyle 后，仍返回相同的一百行。断言检查有类型查询的结果数量，DEALLOCATE 和回滚分别清理预备语句与临时表。这个结果验证当前示例中条件与裁剪的关系；选择索引或调整生产分区粒度前，还应测量有代表性的实际计划，不能直接把小实验的结构当成性能收益保证。

来源

PostgreSQL 表分区，规划期与执行期裁剪、边界及锁行为，已核验 2026-10-15。
PostgreSQL PREPARE，通用与定制计划及参数处理，已核验 2026-10-15。
PostgreSQL 部分索引，规划期谓词蕴含要求，已核验 2026-10-15。

公用表表达式把一个查询先命名再复用

Sun, 19 Dec 2027 00:00:00 +0000

公用表表达式在一条 SQL 内为查询结果命名。它可以先说明数据总体和中间计算，再写最终 SELECT，让复杂报表更容易阅读。这个名字不是持久表，也不自动承诺缓存结果、固定扫描次数或按顺序执行的一组命令。理解 CTE 时，应把可读结构与执行方式分别检查。

先确定作用域，再讨论执行

WITH 子句只属于当前语句。后续语句不能继续引用它的名字，执行结束后也没有一个可供建立索引或查询的 schema 对象。如果计算结果或查询定义需要保留到后续语句继续使用，应选择临时表、视图或其他合适的数据库对象。CTE 适合命名结果与语句作用域相匹配的工作，不能靠命名制造跨请求缓存。

现代 PostgreSQL 可以把非递归、没有 volatile 函数的 SELECT CTE 折叠进外层查询。默认情况下，只引用一次时会进行这种合并，使外层限制参与共同优化。因此，外层按主键查找时，条件可以直接作用于底层表的索引，而不必先生成独立中间结果再过滤。

同一个符合条件的 CTE 被引用多次时，PostgreSQL 默认通常会物化它。这能减少重复昂贵计算，但也可能阻止某个引用位置上的选择性条件被推入共享计算。这个区别从 PostgreSQL 十二开始适用；认为所有 WITH 都是固定优化边界，描述的是旧行为，不能覆盖当前默认规则。应根据实际版本和引用次数检查，而不是依赖旧经验。

物化是一项取舍

MATERIALIZED 请求独立计算。NOT MATERIALIZED 允许多次引用时也进行折叠，可能重复一部分工作，但让每次使用只访问自己需要的数据。对于递归或不是无副作用 SELECT 的 CTE，PostgreSQL 会忽略 NOT MATERIALIZED；它不会因此允许任意复制写入或 volatile 操作。

物化的 SELECT CTE 也不一定完整算到末尾。消费方可能只请求部分结果，不过排序、关联等操作又可能要求读取更多。物化同样不等于为后续语句建立一张带索引的可复用表。决定强制边界之前，应查看计划并测量真实负载，不能因为“物化”听起来像缓存就默认收益更好。

真正需要比较的是总工作量：多次选择性很高的索引查找，可能比构建并扫描大型共享结果便宜；重复昂贵计算又可能更慢。名字清楚与执行高效可以同时实现，但两者不能互相证明。业务条件应保持单一权威定义，执行控制则应在计划和测量支持时使用，而不是为猜想的性能问题增加边界。

坏掉的样子

修改数据的 CTE 使用不同规则。WITH 内的 INSERT、UPDATE、DELETE，以及 PostgreSQL 18 的 MERGE，即使输出没有被读取，也会执行一次并完成。可被引用的命名关系来自 RETURNING 输出，而不是修改后重新扫描目标表得到的结果。没有 RETURNING 的修改仍会发生，只是不能向后面的引用提供行。

修改子语句和主语句使用同一快照，实际修改顺序没有按文本从上到下依次执行的保证。后续部分需要变更后的行时，应通过 RETURNING 传递。不要在一条语句里尝试修改同一行两次，再期待文本位置决定最终结果。外层看起来只是 SELECT，也不能证明整条带 WITH 的语句只读；执行陌生查询时，必须检查内部是否有写操作。

快速验证

把下面内容保存为 cte.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f cte.sql。脚本先比较四个只读计划，再用 DELETE RETURNING 与 INSERT 搬移两条临时数据。末尾回滚会撤销实验中的修改并清除对象。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE items (id integer PRIMARY KEY, value text);
INSERT INTO items SELECT g,'item-'||g FROM generate_series(1,10000) AS g;
ANALYZE items;
EXPLAIN (COSTS OFF)
WITH source AS (SELECT * FROM items) SELECT * FROM source WHERE id=7;
EXPLAIN (COSTS OFF)
WITH source AS MATERIALIZED (SELECT * FROM items) SELECT * FROM source WHERE id=7;
EXPLAIN (COSTS OFF)
WITH source AS (SELECT * FROM items)
SELECT a.id FROM source a JOIN source b USING(id) WHERE a.id=7;
EXPLAIN (COSTS OFF)
WITH source AS NOT MATERIALIZED (SELECT * FROM items)
SELECT a.id FROM source a JOIN source b USING(id) WHERE a.id=7;
CREATE TEMP TABLE moved (id integer,value text);
WITH removed AS (DELETE FROM items WHERE id<=2 RETURNING *)
INSERT INTO moved SELECT * FROM removed;
SELECT (SELECT count(*) FROM items) AS remaining,(SELECT count(*) FROM moved) AS moved;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY id) FROM moved) IS DISTINCT FROM ARRAY[1,2] THEN
 RAISE EXCEPTION 'RETURNING handoff failed';
 END IF;
 IF (SELECT count(*) FROM items) <> 9998 THEN RAISE EXCEPTION 'DELETE did not execute'; END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 中，默认单次引用的计划直接使用 items_pkey。显式 MATERIALIZED 增加 CTE Scan，其输入计划为顺序扫描；默认双次引用也共享一个物化 CTE，而 NOT MATERIALIZED 则形成两次基于索引的访问。这几条普通 EXPLAIN 只展示计划结构，没有测量执行时间，也不能据此宣称生产性能已经改善。

后面的修改语句确实执行了，items 剩余九千九百九十八行，moved 中有两行。断言确认转移的标识恰好是一和二，并确认原表对应行已删除。这里通过 RETURNING 在操作之间交接数据，不依赖目标表重读或文本顺序。减少外层消费量不能安全地阻止修改型 CTE 执行；类似实验应保留事务边界，并在执行前明确所有写入对象。

来源

PostgreSQL WITH 查询，折叠、物化和数据修改型 CTE，已核验 2026-10-15。
PostgreSQL SELECT 参考，WITH 作用域和 MATERIALIZED 控制，已核验 2026-10-15。

记录规则应保留比例的分子和分母

Tue, 31 Aug 2027 00:00:00 +0000

当查询成本和复用频率足以支持预计算时，反复使用的服务级查询适合做成记录规则。关键问题是保存什么。如果只保存每个实例的错误百分比，可能丢掉之后聚合必需的流量规模；同时保存错误速率与请求速率，则保留了分子和分母，消费者能够据此计算按实际请求量加权的服务错误占比，而不是把每台实例当成相同流量。

百分比必须对应明确的总体

假设繁忙实例每秒处理十个请求，每秒发生零点一个错误；空闲实例每秒处理一个请求，却每秒发生零点五个错误。两个实例的错误占比分别为百分之一与百分之五十。直接平均得到百分之二十五点五，相当于给两个实例相同权重，但它们的请求量实际上相差十倍。这个数描述平均实例百分比，不描述服务处理的全部请求。

服务合计每秒处理十一个请求，发生零点六个错误，因此错误占比是 0.6/11，约百分之五点四五。这是聚合错误量除以聚合请求量。两侧必须描述同一组符合条件的流量，并使用相同时间窗口。如果分子排除了分母包含的一类失败，或者两侧聚合了不同服务，面板即使计算得很快，结果也仍然不成立。

按顺序建立规则依赖

先对每条计数器序列应用 rate，使已经观测到的重置能够在聚合前得到处理，再按照消费者确实需要的维度求和。本例依次记录服务与实例维度的请求速率、服务请求速率、服务错误速率，以及最终服务错误占比。第一个实例级中间结果用于展示明确的前后依赖，后续规则实际消费这个结果，而不是重复写一个看似相关的名字。

四条规则位于同一个组，按声明顺序运行，使用相同评估时间。分子与分母都保留匹配的 service 标签，因此除法能够把对应服务配对。如果分母额外保留实例标签，就会改变向量匹配关系，可能导致没有结果，或需要重新设计连接方式。测试应同时检查输出标签和数值，不能只看到一个合理百分比就认为查询正确。

命名应说明聚合层级和范围。两分钟速率与三十分钟速率即使当前值恰好相同，也不是同一种量。应在规则旁记录哪些事件计入总体，并明确消费它的面板与告警。沿用旧名称但修改公式，只会改变未来记录样本，不会重新解释已经写入的历史。需要保持时间可比性时，定义变更必须被消费者看见。

坏掉的样子

平均百分比可能让一台低流量故障实例主导整个服务报告，也可能掩盖高流量实例的失败。提高评估频率不会修复这个算术问题，应恢复底层计数或速率，在分别聚合后再相除。如果最后只保留了百分比，通常无法仅靠这些百分比重建原始流量权重，因为相同占比可以来自完全不同的请求数量。

零流量是另一类情况。分母为零时，错误占比并没有被定义为零；分子缺失也可能代表仪表化缺少序列，而不是没有错误。应根据指标契约明确这些语义，避免自动把所有空结果或未定义数值显示成健康的零。还应确认健康期间错误计数器是否持续导出，避免只有发生错误后才创建序列，导致正常状态与数据缺失难以区分。

快速验证

保存为 recording-weighted.py，在 PATH 中准备已安装的 promtool，或用 PROMTOOL 指定可执行文件，再运行 python3 recording-weighted.py。完整程序在 promtool 3.14.0 与 Python 3.12.14 上通过。真实规则引擎评估每分钟一份的合成计数器，包含权重明显不同的实例，以及独立的零流量、序列缺失案例。

from pathlib import Path
from tempfile import TemporaryDirectory
import os
import shutil
import subprocess

promtool = shutil.which(os.environ.get("PROMTOOL", "promtool"))
if promtool is None:
 raise SystemExit("Set PROMTOOL to an installed promtool executable")
promtool = str(Path(promtool).resolve())
tests = r"""evaluation_interval: 1m
rule_files:
 - rules.yml
tests:
 - interval: 1m
 input_series:
 - series: "http_requests_total{service=\"checkout\",instance=\"busy\"}"
 values: "0+600x5"
 - series: "http_errors_total{service=\"checkout\",instance=\"busy\"}"
 values: "0+6x5"
 - series: "http_requests_total{service=\"checkout\",instance=\"quiet\"}"
 values: "0+60x5"
 - series: "http_errors_total{service=\"checkout\",instance=\"quiet\"}"
 values: "0+30x5"
 promql_expr_test:
 - expr: "service:http_requests:rate2m"
 eval_time: 5m
 exp_samples:
 - labels: "{__name__=\"service:http_requests:rate2m\",service=\"checkout\"}"
 value: 11
 - expr: "abs(service:http_errors:rate2m - 0.6) < bool 1e-12"
 eval_time: 5m
 exp_samples:
 - labels: "{service=\"checkout\"}"
 value: 1
 - expr: "abs(service:http_errors:ratio_rate2m - 0.6/11) < bool 1e-12"
 eval_time: 5m
 exp_samples:
 - labels: "{service=\"checkout\"}"
 value: 1
 - expr: "abs(avg(rate(http_errors_total[2m]) / rate(http_requests_total[2m])) - 0.255) < bool 1e-12"
 eval_time: 5m
 exp_samples:
 - labels: "{}"
 value: 1
 - interval: 1m
 input_series:
 - series: 'http_requests_total{service="idle",instance="one"}'
 values: "0+0x5"
 - series: 'http_errors_total{service="idle",instance="one"}'
 values: "0+0x5"
 promql_expr_test:
 - expr: 'count(service:http_errors:ratio_rate2m != service:http_errors:ratio_rate2m)'
 eval_time: 5m
 exp_samples:
 - labels: "{}"
 value: 1
 - interval: 1m
 input_series: []
 promql_expr_test:
 - expr: 'count(service:http_errors:ratio_rate2m) or vector(0)'
 eval_time: 5m
 exp_samples:
 - labels: "{}"
 value: 0
"""
rules = r"""groups:
 - name: service-rates
 interval: 1m
 rules:
 - record: instance:http_requests:rate2m
 expr: sum by (service, instance) (rate(http_requests_total[2m]))
 - record: service:http_requests:rate2m
 expr: sum by (service) (instance:http_requests:rate2m)
 - record: service:http_errors:rate2m
 expr: sum by (service) (rate(http_errors_total[2m]))
 - record: service:http_errors:ratio_rate2m
 expr: service:http_errors:rate2m / service:http_requests:rate2m
"""
with TemporaryDirectory(prefix="prom-rule-test-") as directory:
 work = Path(directory)
 (work / "tests.yml").write_text(tests, encoding="utf-8")
 (work / "rules.yml").write_text(rules, encoding="utf-8")
 subprocess.run([promtool, "test", "rules", "tests.yml"], cwd=work,
 check=True, timeout=45)

预期输出为 SUCCESS。记录请求速率为十一，错误速率为零点六，最终占比为 0.6/11。另外一项断言明确展示，错误的实例比例平均法得到 0.255。涉及浮点除法的比较使用很小的数值容差，标签断言则确认仍保留 checkout 服务身份。这些检查同时覆盖计算次序、依赖输出和最终聚合口径。

零流量案例得到 NaN，它与自身比较不相等，因此过滤比较保留一条序列；输入缺失时则没有比例序列，两者都不应被当成健康的零。这个本地规则测试不启动监听端，临时文件会清理。它不是性能基准，也不能证明生产仪表化完整。部署前还应补充符合服务实际的重置和入库延迟案例，并测量查询成本及规则耗时，再判断是否有运行收益。

来源

Prometheus: recording rules，有顺序的规则依赖与保存结果，已核验 2026-10-15。
Prometheus: query functions，先计算速率再聚合以识别计数器重置，已核验 2026-10-15。
Prometheus: unit testing rules，验证记录序列与查询结果，已核验 2026-10-15。

EXPLAIN 计划揭示查询路径

Fri, 21 May 2027 00:00:00 +0000

EXPLAIN 展示数据库为语句选择的执行计划，可以帮助定位昂贵工作与错误估算。不过，慢请求也可能涉及锁等待、网络传输或计划之外的应用行为。应利用计划检验一个明确假设，而不是认定每次性能问题都需要换扫描方式或增加索引。计划是诊断证据的一部分，不是整条请求链路的完整时间账本。

读计划树时避免重复计数

在 PostgreSQL 中，叶节点通常扫描关系，上层节点负责连接、排序、聚合或修改行。上层也会做真实工作，不能说全部工作都在叶子。上层成本包含子节点成本，把所有显示的 cost 相加会重复计算。rows 估算表示节点输出的行数，不一定是它检查过的全部行；过滤可以造成输入与输出差距，这本身并不能证明规划错误。

普通 EXPLAIN 只有估算；EXPLAIN ANALYZE 会真正执行语句并补充观察。loops 大于一时，actual rows 与时间通常是每次执行的平均值，要结合循环次数解释。比较估算时，应对照同一节点的实际输出，而不是无关的整表规模。buffers 也包含子节点活动，并不是去重后的页面计数，不能把所有层的数字直接相加当作总读取量。

统计信息影响选择

行数、分布、相关性、查询结构与成本设置都会影响规划。ANALYZE 更新统计信息，但行数估算严重错误，并不唯一指向统计过期。抽样误差、相关谓词、缺少扩展统计和参数选择率，也可能产生偏差。适当时刷新相关统计，再看差距是否真正改善，不要把一次较大的估算偏差当作已经完成根因诊断。

规划器也不是看见刚刚测到的缓存命中率变化，就自动决定改道。effective_cache_size 等设置表达缓存假设；真实缓存冷热可以改变执行时间，即使计划完全相同。比较结果时，应记录数据规模、参数、相关设置和测量条件。查询需要大部分表数据时，顺序扫描可能正是合理选择，不能把出现 Seq Scan 当成索引失效的通用判据。

坏掉的样子

预编译语句要按具体版本解释。PostgreSQL 自动策略可以比较定制计划与通用计划，并不是简单把首次参数的计划固定给所有后续值。应使用有代表性的参数执行 EXPLAIN EXECUTE，检查计划里出现的是常量还是参数占位符。不同数据库产品的缓存机制不同，不能把某一个产品的解释直接套到另一个实现。

函数、类型转换和排序规则，可能让某个索引无法匹配谓词，但不代表一定强制全表扫描。表达式索引可以支持 lower(column)，一些跨类型运算也仍可使用索引。PostgreSQL 遇到不支持的 varchar 与整数比较时，还可能直接拒绝语句，而不是静默转换后扫描。决定改写之前，应检查真实运算符、类型和索引条件，避免凭语法外观推断执行路径。

EXPLAIN ANALYZE 不是无副作用的查看命令。写入、触发器、锁和被调用函数都会实际执行；事务回滚也无法撤销所有效果，例如已经消费的序列值或外部动作。应使用受控数据及合适的测试环境，即使 SELECT 也可能调用具有副作用的函数。诊断前评估负载，不能因为命令以 EXPLAIN 开头，就自动视为生产环境里的安全读取。

确认收益，而不只是计划形状变化

保留可比较的前后结果。计划变了可能更慢，计划形状没变也可能因实际工作量、数据或执行条件改善而更快。应一起查看耗时、输出正确性、行数估算、buffers、loops 和磁盘溢出。cost 单位不是毫秒，低成本估算不保证实际延迟。目标是能解释并复现的收益，不是让计划截图看起来更像预期答案。

快速验证

把下面程序保存为 plan_route_check.py，用 python3 plan_route_check.py 执行。它只使用标准库，在刻意错误的选择率下模拟两条候选路径，不调用 PostgreSQL，也不复现真实优化器。过期输入是这个用例预先设定的事实；告警要求继续调查，不能把所有真实计划里的估算偏差都诊断为统计过期。

#!/usr/bin/env python3
"""教学用规划器模型：按估算成本选路线，按实际行数验路线。

仅用标准库。它模拟统计信息过期：规划器以为只有 500 行命中，
实际有 600,000 行，并检查估算偏差告警是否触发。
"""

from __future__ import annotations


def seq_scan_cost(pages: float, rows: float) -> float:
 return pages * 1.0 + rows * 0.01


def index_scan_cost(selectivity_est: float, pages: float, rows: float) -> float:
 heap_pages = selectivity_est * pages
 return 4.0 + heap_pages * 4.0 + selectivity_est * rows * 0.01


def main() -> None:
 pages, rows = 8_000.0, 1_000_000.0
 stale_selectivity = 0.0005 # 规划器的信念：500 行
 true_selectivity = 0.60 # 现实：600,000 行
 est_rows = stale_selectivity * rows
 actual_rows = true_selectivity * rows

 seq = seq_scan_cost(pages, rows)
 idx_est = index_scan_cost(stale_selectivity, pages, rows)
 idx_true = index_scan_cost(true_selectivity, pages, rows)
 chosen = "索引扫描" if idx_est < seq else "顺序扫描"
 print(f"估算行数：{est_rows:.0f}；实际行数：{actual_rows:.0f}")
 print(f"估算成本：顺序扫描={seq:.1f} 索引扫描={idx_est:.1f} -> 规划器选择{chosen}")
 print(f"实际区分度下的真实成本：顺序扫描={seq:.1f} 索引扫描={idx_true:.1f}")

 error = abs(actual_rows - est_rows) / actual_rows
 print(f"估算偏差：{error:.1%}")
 warned = False
 if error > 0.50:
 warned = True
 print("告警：行数估算偏差超过 50%——请检查统计信息、谓词与参数选择率。")
 if chosen == "索引扫描" and idx_true > seq:
 warned = True
 print("告警：在真实区分度下所选路线更贵——请对照 EXPLAIN ANALYZE。")
 assert warned, "该用例应当触发统计信息过期告警"
 assert est_rows < actual_rows / 10, "用例需保持估算比实际低一个数量级"
 print("PASS：规划器选中了过期路线，估算偏差告警已触发")


if __name__ == "__main__":
 main()

模型按估算选择索引扫描，成本二十五，小于顺序路径的一万八千。在给定实际选择率下，模型的索引成本变成二万五千二百零四；程序输出百分之九十九点九的估算偏差，在告警后输出 PASS。这些成本都是简化公式的结果，不是真实数据库执行耗时，也不是从生产计划中采集的数字。

实验确认算术与预先构造的反例，不验证某个 PostgreSQL 计划，不足以批准增加索引，也不能证明 ANALYZE 会修好线上查询。调整真实负载之前，仍需用实际计划和受控执行证据重复调查。保留玩具模型与数据库实验的区别，才能避免把教学示例的成功误报为优化器已经完成验证。

来源

PostgreSQL：EXPLAIN，生成计划，已核验 2026-10-15。
PostgreSQL：使用 EXPLAIN，解读输出，已核验 2026-10-15。
PostgreSQL：规划器与优化器，路线如何被选定，已核验 2026-10-15。
MySQL：EXPLAIN 语句，计划格式与输出列，已核验 2026-10-15。
PostgreSQL PREPARE，通用计划与定制计划选择，已核验 2026-10-15。
PostgreSQL 表达式索引，包括 lower(column) 的表达式索引，已核验 2026-10-15。

查询 · XB 现场笔记

InnoDB 覆盖索引包含查询所需的列

坏掉的样子

快速验证

有意识地承担覆盖成本

来源

分区裁剪跳过查询不可能用到的整张分区

证明哪些分区不可能命中

参数也能在执行时触发裁剪

坏掉的样子

快速验证

来源

公用表表达式把一个查询先命名再复用

先确定作用域，再讨论执行

物化是一项取舍

坏掉的样子

快速验证

来源

记录规则应保留比例的分子和分母

百分比必须对应明确的总体

按顺序建立规则依赖

坏掉的样子

快速验证

来源

EXPLAIN 计划揭示查询路径

读计划树时避免重复计数

统计信息影响选择

坏掉的样子

确认收益，而不只是计划形状变化

快速验证

延伸阅读

来源