数据库索引详解：给你的应用一本电话簿

数据库索引，简单说就是：每个索引都像一本电话簿——不必翻遍每一页去找一个名字，而是直接跳过去。没有索引时，数据库要读遍一张表的每一行才能回答一个问题。有了索引，同样数据上的一次真实查询从2,300毫秒降到了2.3毫秒——快了一千倍——因为它扫描的是47行匹配的数据，而不是500,000行。

索引是你能碰到的杠杆率最高的性能工具，不需要改任何代码，而AI还经常忘了加。这里讲它们是什么、覆盖90%场景的那一条规则，以及能说明利害关系的真实生产数据。

数据库索引详解：什么是数据库索引？

想想你怎样在电话簿里找“Gonçalves”。你不会从第一页开始逐条读——你利用的是电话簿是排好序的，直接跳到G附近，几秒钟就找到了这个名字。现在想象同一本电话簿，条目是随机排列的。找一个名字就意味着每次都要读完整本书，每次查找都是如此。

第二本电话簿，就是没有索引的数据库表。表里的行没有任何有用的顺序，所以像“显示这位客户的任务”这样的问题，会迫使数据库检查每一行并留下匹配项——这叫全表扫描。索引就是数据库在一旁维护的那本排好序的电话簿：一个针对某一列（或几列）的快速查找副本，让它可以直接跳到匹配的行。

换成用户体验的说法：2.3秒是你的客户眼睁睁看着页面加载的时间。2.3毫秒就是瞬间。同样的查询，同样的数据——唯一的区别就是一个索引。

规则：为每一个外键建索引

你不需要成为性能工程师。一条规则就能覆盖绝大多数现实场景：

为每一个外键，以及每一个经常用来过滤或排序的列建索引。

外键就是指向另一张表的任何列——任务所属的客户、发票所计费的项目、记录所带的状态。在一个结构良好的数据库中（也就是正确规范化得到的那种），这些引用列无处不在，而它们恰恰是数据库回答问题时用来连接各表的依据。每一个都要建索引。没有例外，无需权衡。

除此之外，还要为你的界面不断过滤和排序的列建索引：每一行所属的组织（多租户应用的骨干，几乎每次查询都要过滤它）、用于“最新优先”列表的创建日期，以及几乎每个查询都要检查、用来隐藏已删除记录的软删除时间戳。习惯很简单：建表时每列一行代码——CREATE INDEX idx_tasks_project_id ON tasks(project_id);——而这个习惯AI不会替你保持：生成的数据库结构通常会定义引用，却跳过索引，这在只有50行的演示里运行完美，到了500,000行就崩溃。

本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →

复合索引：电话簿的第二个技巧

电话簿不是只按一个条件排序的——它先按姓排序，再按名排序。这让你能找出所有“Smith”，或者精确找到“Smith, John”。它做不到的，是不论姓氏找出所有叫“John”的人——那样你又得读完整本书了。

复合索引是同样的结构，只是建立在两列或更多列之上，并遵循同样的从左到右法则。建立在（组织，状态）上的索引，能加速“这个组织的所有内容”和“这个组织中处于该状态的所有内容”——但对“所有组织中处于该状态的内容”毫无帮助，因为状态是名，不是姓。

实际的后果是：列的顺序很重要。把你总是用来过滤的列放在最前面——在多租户产品中，那就是组织。复合索引还有一项额外的能力：如果索引的顺序与你的查询排序顺序一致，结果出来时就是排好序的，完全省掉排序步骤。

什么时候不该建索引

索引不是免费的：每个索引都占用磁盘空间，并且在每次写入时都要更新，所以每多一个索引，插入和更新就会慢一点。有四种情况应该跳过：

只有两个取值的列。真/假标记把表大致分成两半——跳到“半本书”并不能省下什么。小表。不到约1,000行时，整张表读起来基本是瞬间的；主键就够了。你从不搜索的列。只有出现在过滤、排序或连接中的列才值得建索引——自由文本备注则不值得。写入密集型表中不断变化的列。每次变化也都必须更新索引；对于主要写入、很少读取的表，这笔交易是亏的。

黄金法则：每个索引都应该用可衡量的查询改善来证明自己存在的理由。“以防万一”式的索引，只会让你落得写入慢且磁盘浪费的下场。

真实的生产数据

三组真实的前后对比测量，每一组都是SaaS产品中常见的界面：

每一行都是同一个故事：数据库不再读取全部，而是开始直接跳转。产生这些结果的流程，任何创始人都能重复：找到慢的界面，让数据库解释它是如何回答这个查询的（每个数据库都有“explain”功能——让AI来解读其输出效果极好），加上解释所指向的索引，再测一次。当报告写着“扫描了500,000行，只返回20行”时，你就找到了缺失的索引。

12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →

常见问题

如何找出我缺失的索引？

顺着慢的地方找。当某个页面卡顿，取出它的查询，在数据库上运行explain功能，查找全表扫描——报告会直接告诉你读取了多少行、返回了多少行。现代数据库的控制台也会列出最慢的查询，通常还会直接建议缺失的索引。把这些内容贴给AI，让它用大白话解读。

索引会不会建太多？

会。每个索引都要对每次写入收税并占用磁盘，所以一张有十几个“预防性”索引的表，是在为假想的查询付出真实的代价。先从规则开始——外键、组织、常见过滤条件——只有当某个测得的慢查询提出需要时，再增加更多，并清理没人使用的索引。

索引也会加快写入吗？

不会——恰恰相反，会稍微变慢。索引加速读取，但数据变化时它自己也必须更新，所以每个索引都会让写入多交一点税。对于读远多于写的典型SaaS产品，这笔交易绝对划算；只是别给从不被搜索的列建索引。

AI会自动替我加索引吗？

有时会，但不稳定——而忘记为外键建索引，是AI生成的数据库结构中最常见的疏漏之一，因为没有它们，演示也能运行得很好。把话说明白：告诉AI它创建的每张表都必须为外键和常用过滤列建索引，并像核对清单一样，对照这条规则检查数据库结构。