标签: #query-optimization
关于 GPU、LLM、MLOps、Kubernetes 以及心态的文章 · 4 篇
建了索引却不走索引的原因 — 那些优化器对而你错的情况
本文按原因梳理为什么建了索引之后执行计划里依然是 Seq Scan。选择性太低导致优化器故意忽略、列上套了函数或运算而不再 sargable、类型不匹配触发隐式转换、LIKE 前导通配符、OR 条件、复合索引的前导列规则、统计信息老化,直到 NULL 的处理,全部用真实 SQL 和执行计划来确认。同时也讨论部分索引与表达式索引成为答案的场景,以及索引反而有害的情况。
2026-07-26 · 18 分钟阅读 #database#postgresql#index#query-optimization#mysqlEXPLAIN ANALYZE 阅读法 — 从执行计划中找出真正瓶颈的顺序
本文梳理如何从头到尾读懂 EXPLAIN ANALYZE 的输出。应该按什么顺序读节点,cost 为什么不是时间单位,预估行数与实际行数之间的偏差说明了什么,loops 会被相乘的陷阱又该如何避开,全部结合真实输出来讲解。同时涵盖 Nested Loop、Hash Join、Merge Join 各自被选中的条件,以及如何用 BUFFERS 判断缓存命中。文章还会给出依据,说明 Seq Scan 并不总是坏事。
2026-07-26 · 17 分钟阅读 #database#postgresql#explain#query-optimization#performanceClickHouse 的 Lazy Materialization — LIMIT 10 的小技巧是如何长成 FINAL 和 JOIN 的
ClickHouse 的 lazy materialization 是一种在排序和 LIMIT 完成之前不读取 SELECT 列的优化，它在 25.4(2025 年 4 月)以「仅在 LIMIT 10 及以下时才生效」的保守姿态首次登场。此后，在把逐行 lookup 改造成 join 式批量获取的 25.12 中，这道闸门被提高到 10,000；进入 2026 年后，同一个思路又扩展到 26.2 的 UNION ALL 全部分支、26.
2026-07-17 · 22 分钟阅读 #database#clickhouse#olap#query-optimization#performancePostgres 19 的 pg_plan_advice — 一个长期拒绝提示的项目给出的妥协方案
PostgreSQL 项目长期以来一直拒绝优化器提示(hint)。但在 2026 年 6 月 4 日发布的 PostgreSQL 19 Beta 1 中，Robert Haas 编写的 pgplanadvice 和 pgstashadvice 作为 contrib 模块被合并了进去。这不是 Oracle 式的提示 — 建议(advice)活在 SQL 之外，它不是替代规划器，而只是收窄搜索空间，用文档自己的话说，出来的"只会是核心规划器
2026-07-16 · 22 分钟阅读 #postgresql#query-planner#query-optimization#database#performance