1. 没有索引时，可能要全表扫描#

假设有一张很大的用户表：

1
SELECT id, name, email
2
FROM users
3
WHERE email = 'owen@example.com';

返回结果本身很简单：

如果 email 没有索引，数据库可能需要从头到尾检查很多行，才能找到匹配记录。这就是全表扫描。

数据量小的时候无所谓，数据量大以后就会变慢。

2. 索引像一本目录#

给 email 建索引：

1
CREATE INDEX idx_users_email ON users(email);

之后再按 email 查询，数据库可以先查索引，再定位到对应行。它不必把整张表都扫一遍。

主键通常天然有索引，所以按 id 查一般很快：

1
SELECT *
2
FROM users
3
WHERE id = 1;

可以把索引粗略想象成一本书后面的目录。没有目录时，只能一页页翻；有目录时，可以先定位关键词在哪些页，再去看正文。

3. 哪些字段适合建索引#

常见候选包括：

• 经常出现在 WHERE 里的字段。
• 经常用于 JOIN 的字段。
• 经常用于排序的字段。
• 高选择性的字段，也就是能过滤掉大量数据的字段。

例如订单表里，user_id 经常用于查询某个用户的订单：

1
CREATE INDEX idx_orders_user_id ON orders(user_id);

如果经常查询某个用户的最近订单，可以考虑联合索引：

1
CREATE INDEX idx_orders_user_created_at ON orders(user_id, created_at);

联合索引的顺序很重要。(user_id, created_at) 更适合这类查询：

1
SELECT id, total_amount, created_at
2
FROM orders
3
WHERE user_id = 1
4
ORDER BY created_at DESC
5
LIMIT 20;

因为查询先按 user_id 缩小范围，再在这个用户的订单里按时间排序。

4. 让查询更容易用上索引#

有些写法会让索引难以发挥作用。比如在字段上套函数：

1
SELECT id, email
2
FROM users
3
WHERE LOWER(email) = 'owen@example.com';

如果只有普通的 email 索引，数据库不一定能直接使用它。更常见的做法是提前规范化存储，或者为表达式单独建索引，具体取决于数据库能力。

再比如模糊匹配：

1
WHERE email LIKE '%@example.com'

前面有 % 时，普通 B-tree 索引通常很难直接加速。搜索类需求可能需要全文索引、倒排索引，或者专门的搜索引擎。

入门阶段先记一个词：sargable。它大概表示查询条件能不能有效利用索引。我们不必马上背术语，但要有这个直觉：条件写法会影响数据库怎么找数据。

5. 索引不是越多越好#

索引会加快读取，但也有成本：

• 占用额外存储空间。
• 插入、更新、删除时也要维护索引。
• 索引太多会让优化器选择变复杂。

所以索引应该服务具体查询，不是看到字段就加。

一个比较稳的学习顺序是：

1. 先写清楚业务查询。
2. 观察慢在哪里。
3. 看执行计划。
4. 给高频慢查询补索引。
5. 再验证是否真的变快。

6. EXPLAIN：让数据库解释它怎么查#

不同数据库的执行计划命令略有差异，但常见入口是 EXPLAIN：

1
EXPLAIN
2
SELECT id, name, email
3
FROM users
4
WHERE email = 'owen@example.com';

没有索引时，执行计划可能类似这样：

加了索引后，可能变成：

不同数据库的真实字段名不一样，但我们先抓住核心：有没有从全表扫描变成索引扫描。

执行计划会告诉我们数据库准备怎么执行查询，比如是否使用索引、扫描多少行、JOIN 顺序是什么。

学习阶段不用一开始看懂所有字段，但可以先关注：

• 有没有全表扫描。
• 有没有使用预期索引。
• 预估扫描行数是否很大。
• JOIN 是否导致结果暴涨。

如果用 MySQL，EXPLAIN 的结果通常会包含这些字段。比如 users.email 没有索引时：

1
EXPLAIN
2
SELECT id, name, email
3
FROM users
4
WHERE email = 'owen@example.com';

可能看到类似结果：

这几个字段可以先这样理解：

这时给 email 建一个索引：

1
CREATE INDEX idx_users_email ON users(email);

再看执行计划，可能变成：

这里的变化就很关键：

• type 从 ALL 变成 ref，说明不再全表扫描，而是按索引查找。
• key 变成 idx_users_email，说明真的用上了刚才创建的索引。
• rows 从 1000000 变成 1，说明预计扫描量大幅下降。

所以看 EXPLAIN 时，不是为了背字段，而是为了回答三个问题：

1. 有没有走索引？
2. 扫描行数是不是太多？
3. 有没有额外排序、临时表、回表等成本？

再看一个排序例子：

1
EXPLAIN
2
SELECT id, total_amount, created_at
3
FROM orders
4
WHERE user_id = 1
5
ORDER BY created_at DESC
6
LIMIT 20;

如果只有 user_id 单列索引，可能会看到：

Using filesort 表示数据库还需要额外排序。它不一定真的写磁盘文件，但说明排序没有完全被索引顺序接住。

如果这个查询很高频，可以考虑联合索引：

1
CREATE INDEX idx_orders_user_created_at
2
ON orders(user_id, created_at);

再看执行计划，可能变成：

这就说明数据库可以先按 user_id 定位，再利用索引里已经排好的 created_at 顺序取最近 20 条，少做很多排序工作。

如果用 PostgreSQL，还可以在测试环境看更具体的执行情况：

1
EXPLAIN ANALYZE
2
SELECT id, name, email
3
FROM users
4
WHERE email = 'owen@example.com';

返回结果除了计划，还会带实际执行时间、实际扫描行数等信息，形状可能像：

ANALYZE 会实际执行查询，所以不要在生产库上随便对高成本写法使用它。

7. 不同数据库里的索引长得不一样#

"索引"不是某一种固定结构，而是一类思想：用额外的数据结构，换取更快的查找、排序或相似度搜索。

不同数据库的目标不同，所以索引设计也不一样。

1
CREATE INDEX idx_users_email ON users(email);

1
CREATE INDEX idx_orders_user_created_at ON orders(user_id, created_at);

1
SELECT id, total_amount, created_at
2
FROM orders
3
WHERE user_id = 1
4
ORDER BY created_at DESC
5
LIMIT 20;

1
CREATE INDEX idx_users_email ON users(email);

1
GET user:1

1
ZADD user_score 98 user:1
2
ZADD user_score 85 user:2
3
ZREVRANGE user_score 0 9 WITHSCORES

1
SET user_email:owen@example.com user:1
2
GET user_email:owen@example.com

8. AI 应用里的性能问题#

AI 应用经常会把"自然语言问题"转成数据库查询。这时性能风险更明显：

• 用户问题很开放，模型可能生成无边界查询。
• 缺少 LIMIT 会返回大量数据。
• 模型可能 JOIN 很多表。
• 模型可能在大字段上做模糊搜索。
• 错误聚合可能拖慢整库。

所以 Text2SQL 和数据库 Agent 不应该只验证"语法能不能跑"，还要验证"查询是否安全、可控、不会拖垮系统"。

一个简单的防线是：

• 只开放只读账号。
• 设置查询超时。
• 限制返回行数。
• 对生成 SQL 做静态检查。
• 高风险查询先解释给人看，再执行。

性能优化可以很深，但入门阶段先记住一句话：索引是为了减少不必要的扫描，执行计划是为了少靠猜。