leandex: 保持 PostgreSQL 索引精简高效

leandex 能让 Postgres 保持索引精简高效：检测索引膨胀、安全重建，并完整留存索引重建历史记录。

无需安装扩展、无需后台守护进程的索引维护方案。leandex 是一套纯 SQL / PL/pgSQL 实现的控制平面，用于保守式自主索引重建，设计理念与 pg_ash、PgQue 一致：尽量不向业务库安装额外扩展。

它独立部署在专属控制库中，通过 postgres_fdw 用户映射和 dblink 连通目标数据库，仅使用 CONCURRENTLY 方式重建索引。无需在目标业务库创建任何模式、无 C 扩展、无需配置共享预加载库、无需部署附属守护进程、无需重启数据库。

项目生产定位非常明确：安全的自动化索引重建。leandex 不会主动删除索引，也不会推荐新建索引。

为什么选择 leandex

索引膨胀看似不起眼，却会悄悄拖累 Postgres 所有核心资源：缓冲区缓存、存储空间、磁盘 I/O、备份体积、从库延迟、故障切换耗时、维护窗口效率。

手动重建索引只适用于单库场景，无法适配大规模数据库集群；而简陋的自动化工具隐患更多：阻塞业务流量、无操作历史记录、误重建索引、操作过程不透明。

leandex 提供稳健的折中方案：

• 识别实际大小远超基准值的膨胀索引；
• 采用 Postgres 原生的并发重建机制完成索引重构；
• 在数据库中持久化保存索引状态与重建历史；
• 支持运维人员查看、模拟执行、暂停任务、自定义调度、全程审计。

它是面向 DBA 的自动化运维工具，而非智能索引优化顾问。只自动化本该重复枯燥的索引维护工作，把高风险的索引新增、删除决策留给人工和独立管控工具处理。

leandex 能做什么

• 基于轻量基准比率算法检测索引膨胀；
• 对符合条件的索引执行 CONCURRENTLY 并发重建；
• 在 leandex.index_latest_state 表记录索引最新状态；
• 在 leandex.reindex_history 表留存每一次重建操作记录；
• 独立运行在专属控制库（默认 leandex_control）；
• 单个控制库可管理多个目标业务库；
• 采用 postgres_fdw 用户映射认证，摒弃明文 dblink 连接串；
• 支持 pg_cron 或任意外部定时工具调度；
• 完全无需在目标业务库安装任何模式、表、函数。

leandex 刻意不做什么

leandex 不会：

• 删除任何索引；
• 推荐缺失索引；
• 自动创建替代索引；
• 重构表存储结构；
• 依赖仅超级用户可安装的 C 扩展；
• 向目标业务库植入任何对象。

这种边界划分是刻意设计。索引新建和删除属于高风险操作，若混入自动重建逻辑，会彻底破坏安全可控性。

快速入门

环境要求：

• Postgres 13 及以上版本；
• 准备一个专属控制库，示例：postgres；
• 控制库需安装扩展：
  • postgres_fdw
  • dblink
  • pg_cron（可选，仅用于库内定时调度）；
• 准备一个数据库角色，拥有目标库索引查看、并发重建索引的足够权限。

单文件 SQL 部署方式

直接通过 psql 部署：

psql -h your_host -U your_user -d postgres

psql 内执行：

create extension if not exists postgres_fdw;
create extension if not exists dblink;
\i leandex.sql

leandex.sql 是正式部署文件；拆分的多个 SQL 文件仅用于开发调试和代码比对。

工具对比

补充说明：

• pg_repack 功能强大，适合需要表级重构的场景，但多数云托管环境无法部署；
• pgstattuple 可精准测量膨胀，但依赖扩展、无自动化调度能力；
• postgres-checkup 侧重健康巡检与报表，leandex 侧重可控的索引重建执行；
• leandex 刻意不做索引推荐，此类高风险操作应独立走人工评审流程。

参考

leandex：https://github.com/NikolayS/leandex