git-lrc：每次提交自动运行的 AI 代码审查

你好，我是 Maneshwar。我正在开发 git-lrc，这是一款会在每次 commit 时运行的 AI 代码审查工具。它完全免费，并已在 GitHub 上开放源代码。欢迎为我们点 Star，帮助更多开发者发现这个项目。也请试用一下，并分享你的反馈，帮助我们改进产品。

如果你曾经为了等待一条数据库查询执行完成而耗费太长时间，就一定体会过性能低下带来的痛苦。

好消息是什么？索引可以拯救你！

PostgreSQL 功能强大，但如果没有正确建立索引，你的数据库可能会慢得像在土豆上运行一样。

索引是实现极速查询的秘诀，但也需要付出相应的代价。

PostgreSQL 中的索引就像书籍的目录——你不必逐页扫描（逐行扫描），而是可以直接跳转到相关部分。

如果没有索引，PostgreSQL 会执行顺序扫描，也就是检查每一行来寻找匹配项。这显然不利于性能。

索引尤其适合：

加速带有 WHERE 子句的查询。

提升 join 性能。

使用索引后，查询速度可以从线性提升为对数级。

想象一下，复杂度从 O(n) 降到 O(log n)。

但是……索引并不是魔法，它也存在取舍。

索引会占用存储空间，还可能降低写入速度。

因此，你需要明智地判断应该在何处、何时使用索引。

索引的工作原理：B-tree 的魔法

PostgreSQL 默认使用的索引类型是 B-tree（Balanced Tree，平衡树）。

你可以把它看成一种树状结构，它会让数据保持有序，从而实现快速搜索。它的工作方式如下：

根节点（Root Node）：所有搜索的起点。

分支节点（Branch Nodes）：引导搜索过程到达正确的叶节点。

叶节点（Leaf Nodes）：保存实际的数据指针。

例如，如果你要在一张表中搜索名字 “Mac”，B-tree 会：

将 “Mac” 与当前节点进行比较。

根据比较结果向左或向右遍历。

重复上述过程，直到找到完全匹配的结果。

这个过程减少了所需的比较次数，让搜索速度提升到对数级。

当索引能够显著提升读取性能时，就应该使用它。常见场景包括：

不应该使用索引的情况

每次执行 INSERT、UPDATE 或 DELETE 时，索引也需要随之更新。

这可能会拖慢写入密集型工作负载。在以下情况下，应避免使用索引：

表很小（PostgreSQL 无论如何都能快速完成扫描）。

查询很少根据已建立索引的列进行过滤。

表的写入非常频繁，而且读取速度并不重要。

数据库具有大量事务，并且需要快速完成插入和更新。

PostgreSQL 的 MVCC 机制可能产生 “Heap-Only Tuples”（HOT）更新，进而形成死行并增加 I/O。

衡量索引性能

不要盲目添加索引，先测试它们是否真的有效。

PostgreSQL 提供了 EXPLAIN ANALYZE，用来分析查询的执行时间。可以尝试：

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com';

观察执行计划中出现的是 Seq Scan（不好），还是 Index Scan（好）。

如果添加索引并没有缩短查询时间，那么它就不值得保留。

想删除一个无用的索引？可以使用：

DROP INDEX index_name;

PostgreSQL 中的索引类型

并非所有索引都完全相同。PostgreSQL 提供了多种索引类型：

B-Tree 索引（默认）

几乎所有数据库都会使用一些 B-tree 索引。

B-tree 会尽量保持平衡，让树中每个分支所包含的数据量大致相同。

因此，为了找到目标行而需要遍历的层数，通常都处于相近的范围。

B-tree 索引可以高效处理等值查询和范围查询。

它们适用于所有数据类型，也可以用来检索 NULL 值。

B-tree 对缓存非常友好，即使只有一部分索引被缓存，也能良好工作。

非常适合：等值查询和范围查询（=、<、<=、>、>=）。

  CREATE INDEX idx_users_email ON users(email);

Hash 索引（PostgreSQL 10+ 已改进）

在 PostgreSQL 10 之前，Hash 索引只适用于等值比较，但你基本不应该使用它们，因为它们不具备事务安全性，数据库崩溃后需要手动重建，而且不会被复制到 follower。因此，与 B-Tree 相比，它们的优势非常有限。

从 PostgreSQL 10 开始，Hash 索引支持 write-ahead logging，并且可以复制到 follower。

针对等值比较（=）进行了优化。

不适合范围查询（>、<）。

  CREATE INDEX idx_users_hash_email ON users USING hash(email);

GIN（Generalized Inverted Index，广义倒排索引）

当一个索引需要把多个值映射到同一行时，GIN 非常有用；而 B-Tree 索引针对一行只有一个键值的情况进行了优化。

GIN 很适合为数组值建立索引，也适合实现全文搜索。

用于全文搜索和 JSONB 字段。

  CREATE INDEX idx_users_bio ON users USING gin(to_tsvector('english', bio));

GiST（Generalized Search Tree，广义搜索树）

GiST 索引允许你构建通用的平衡树结构，可用于等值比较和范围比较之外的操作。

它们可用于为几何数据类型建立索引，也可以用于全文搜索。

针对几何查询和范围查询进行了优化。

用于 PostGIS（空间数据索引）。

  CREATE INDEX idx_locations ON places USING gist(location);

BRIN（Block Range INdex，块范围索引）

适用于规模庞大、按顺序存储的数据，例如时间序列数据。

占用的存储空间比 B-Tree 更少。

  CREATE INDEX idx_logs_timestamp ON logs USING brin(timestamp);

高级索引策略

如果多个列经常被一起查询，可以为它们建立多列索引。

CREATE INDEX idx_orders_user_date ON orders(user_id, order_date);

只有 B-tree、GiST、GIN 和 BRIN 索引类型支持多键列索引。

索引能否包含多个键列，与能否向索引添加 INCLUDE 列是相互独立的。

一个索引最多可以包含 32 列，其中包括 INCLUDE 列。

只为部分数据建立索引，以节省空间。

CREATE INDEX idx_active_users ON users(email) WHERE is_active = true;

部分索引（partial index）是仅针对表中部分数据构建的索引，这部分数据由条件表达式定义。

索引只包含满足条件的表行所对应的条目。

在索引中存储额外的列，从而避免访问主表。

CREATE INDEX idx_orders_covering ON orders(user_id, order_date) INCLUDE (total_price);

PostgreSQL 中的所有索引都是二级索引，这意味着每个索引都与表的主数据区域分开存储。

高效确保列值的唯一性。

CREATE UNIQUE INDEX idx_unique_email ON users(email);

索引还可以用于强制保证某个列值的唯一性，或者多个列组合值的唯一性。

只有 B-tree 索引可以声明为 unique。

取舍：读取性能与写入性能

如果你的应用以读取为主，使用索引几乎不需要犹豫。如果应用以写入为主，则应该有选择地使用索引。

索引是 PostgreSQL 中最强大的性能提升手段之一。请明智地使用它们：

✅ 使用索引优化过滤、排序和 join。

❌ 避免在频繁更新的表上建立索引。

🛠 添加索引前，先使用 EXPLAIN ANALYZE 进行测试。

🎯 根据查询模式选择正确的索引类型。

PostgreSQL 索引文档

理解 B-tree

索引最佳实践

PostgreSQL 数据库索引简介

*AI agents 编写代码的速度很快，但它们也会悄无声息地删除逻辑、改变行为并引入 bug——而且不会告诉你。你往往要等到生产环境出现问题后才会发现。

git-lrc 解决了这个问题。它会接入 git commit，在每一份 diff 落地之前完成审查。只需 60 秒即可完成设置，而且完全免费。*

欢迎提供任何反馈，也欢迎贡献者加入！它已经在线运行、开放源代码，任何人都可以直接使用。

在 Commit 时运行的免费微型 AI 代码审查

| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |

在 Commit 时运行的免费微型 AI 代码审查

AI agents 编写代码的速度很快，但它们也会悄无声息地删除逻辑、改变行为并引入 bug——而且不会告诉你。你往往要等到生产环境出现问题后才会发现。

git-lrc 解决了这个问题。它会接入 git commit，在每一份 diff 落地之前完成审查。只需 60 秒即可完成设置，而且完全免费。

看看 git-lrc 如何发现严重的安全问题，例如凭据泄露、成本高昂的云端操作，以及日志语句中的敏感信息。

🤖 AI agents 会悄无声息地破坏代码。代码被删除，逻辑被更改，边界情况消失。直到问题进入生产环境，你才会注意到。

🔍 在发布之前发现问题。由 AI 驱动的行内评论会准确告诉你哪些地方发生了变化，以及哪些地方可能存在问题。

部分评论可能仅对已登录的访客可见。请登录以查看所有评论。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。