企业官网建设流程全解析

1. 从“框架快”到“接口慢”：问题往往出在数据查询上

用FastAPI写接口，第一感觉确实爽。类型注解配合Pydantic做参数校验，async语法天然支持高并发，Swagger文档自动生成，对比Flask那一套“路由函数自己装饰、参数全靠手动parse”的老玩法，开发效率高出一大截。而且FastAPI底层走的是Starlette，启动性能、路由匹配、并发处理在纯Python框架里都是第一梯队。很多人选它就是冲着“性能好”这三个字去的。

但实际上线跑一阵就会遇到一个尴尬场景：吞吐量上去了，响应时间却没跟上。并发100个请求，CPU一点不忙，数据库连接池却撑得满满的。接口动不动几百毫秒甚至上秒级响应，前端疯狂报loading。这时候别再盯着FastAPI本身折腾了，问题99%出在SQL查询上——更准确地讲，出在索引上。

我见过不少团队，把FastAPI和Flask放在一起对比了半天，最后因为性能选了FastAPI，结果线上接口慢得跟PHP似的。排查下来发现，ORM模型压根没加索引，关键字段每一次查询都在做全表扫描。数据量小的时候没感觉，表里一过50万行，性能断崖式下跌。所以这篇就把我在FastAPI项目里做索引优化的完整经验整理出来，从原理到实操，从建索引到查慢SQL，一次性说透。

这篇文章适合谁看？刚用FastAPI写完CRUD、准备上线的开发者；接口响应已经变慢、正在排查瓶颈的后端工程师；以及对数据库索引只停留在“知道有这东西”层面的同学。看完你至少能独立完成一次从建表到索引设计、到性能验证的完整优化闭环。

2. 慢接口背后的真相：搞懂索引的三个核心问题

2.1 数据库“找数据”的两种方式，代价天差地别

一个表没有索引，相当于一本没有目录的书。想找某个关键词，只能从第一页翻到最后一页，这叫全表扫描。在MySQL里，全表扫描意味着InnoDB存储引擎需要把聚簇索引的叶子节点数据页从头到尾读一遍，每一条记录都要过一遍查询条件。500万行的表，哪怕只查一条满足条件的数据，也要扫500万行。

有了索引就不一样了。索引的本质是额外的数据结构，MySQL默认用B+Tree组织，相当于给数据建了一棵“目录树”。从根节点到叶子节点，走的是二分查找的路子，三层B+Tree就能覆盖上千万条记录。也就是说，在一张几千万行的表里做一次点查询，走索引只需要读三四个数据页，耗时从“秒级”直接降到“毫秒级”。

所以判断一个接口慢不慢，先别看代码，先看你的SQL到底在“翻书”还是在“查目录”。

2.2 B+Tree索引：为什么数据库不选二叉树、不选哈希表

可能有人会问：哈希表不是更快吗？O(1)复杂度，比B+Tree的O(logN)好多了。哈希索引确实存在，但只适用于等值查询。一旦遇到范围查询、ORDER BY、GROUP BY、模糊匹配，哈希就完全帮不上忙。一棵红黑树或AVL树虽然可以做范围查询，但树的高度随数据量增长太快，几百万条记录就得好几十层高，而B+Tree因为每个节点能存大量键值，深度很浅，三层基本够用。

B+Tree还有一个杀手级特性：叶子结点之间通过双向指针串成链表。这意味着范围查询只需要找到起点，然后沿着链表的指针顺序往下拎就行了，不需要每次都从根节点重新遍历。这是B+Tree相比于B-Tree的重大改进，也是InnoDB选择它作为默认索引结构的关键原因。

提示：面试和实际排查中，“为什么用B+Tree”是一个高频问题，但真正指导实践的点在于——当你设计索引时，要优先考虑等值查询+范围查询的组合场景，这正是B+Tree最擅长的事。

2.3 聚簇索引和非聚簇索引：一次回表等于一次随机IO

InnoDB的数据本身就按照主键组织成了一棵B+Tree，这叫聚簇索引。表里的每行数据都挂在主键索引的叶子节点上。除了主键之外的索引，都叫二级索引（非聚簇索引），它们的叶子节点存的不是完整行数据，而是主键值。

这两者一结合，就带出了索引优化最重要的一个概念——回表。比如你在name字段上建了索引，执行SELECT * FROM user WHERE name = '张三'时，过程是：先去name索引的B+Tree里找到张三对应的主键id，然后再拿着这个id去主键索引的B+Tree里找完整行数据。

第一次查询走了索引，很快；第二次按主键查询，也很快。问题在于这两次是两次独立的B+Tree检索，回表本质上等于多了一次随机IO。数据量大、并发高的时候，回表的代价会被放大。

那么优化方向就变得清晰了：要么让二级索引覆盖所有需要的字段，省掉回表这一步，这叫覆盖索引；要么把索引设计得更精准，减少不必要的回表次数。

3. FastAPI项目中的索引实战：从ORM定义到迁移落地

3.1 在Model里定义索引的正确姿势

FastAPI本身不管数据库，ORM用的最多的是SQLAlchemy。定义索引有两种方式。第一种是直接在字段上声明index=True，适合单列索引：

from sqlalchemy import Column, String, BigInteger, DateTime, func from sqlalchemy.orm import declarative_base Base = declarative_base() class User(Base): __tablename__ = "users" id = Column(BigInteger, primary_key=True, autoincrement=True) name = Column(String(64), nullable=False, index=True) email = Column(String(128), nullable=False, unique=True) created_at = Column(DateTime, server_default=func.now())

unique=True本身就会创建唯一索引，所以email字段虽然没写index=True，查询时依然走索引。如果某个字段既要加速查询，又要保证唯一性，直接用unique=True就够了。

第二种方式是在__table_args__里声明联合索引：

class Order(Base): __tablename__ = "orders" id = Column(BigInteger, primary_key=True, autoincrement=True) user_id = Column(BigInteger, nullable=False) status = Column(String(20), nullable=False, default="pending") order_no = Column(String(64), nullable=False, unique=True) created_at = Column(DateTime, server_default=func.now()) __table_args__ = ( # 联合索引：优先user_id等值筛选，再用created_at排序 Index("idx_user_created", "user_id", "created_at"), # 覆盖查询需求的联合索引 Index("idx_user_status_created", "user_id", "status", "created_at"), )

这里有个很容易犯的错：在建联合索引时，字段顺序不是随便排的。MySQL索引最左前缀法则决定了，查询条件里必须包含联合索引的最左字段，索引才可能被用到。idx_user_created的顺序是user_id在前、created_at在后，那它可以加速WHERE user_id = ?和WHERE user_id = ? ORDER BY created_at，但加速不了WHERE created_at >= ?。

所以字段排序的原则是：等值查询的字段放前面，范围排序的字段放后面。如果你平时主要按user_id查订单，再按时间排序，那(user_id, created_at)就是合理顺序。如果你经常单独按created_at范围查询，就不能指望这个联合索引，得单独给created_at建索引。

3.2 通过Alembic生成并验证迁移脚本

模型改完之后，很多人直接Base.metadata.create_all()，这在开发环境无所谓，生产环境千万别这么干。表结构变更必须走迁移工具，SQLAlchemy全家桶的标准方案是Alembic。

安装：

pip install alembic

初始化：

alembic init alembic

修改alembic/env.py，把数据库连接串和target_metadata指向你的Base：

from your_models_module import Base from sqlalchemy import create_engine DATABASE_URL = "mysql+pymysql://user:password@localhost/fastapi_app?charset=utf8mb4" engine = create_engine(DATABASE_URL) target_metadata = Base.metadata

然后生成迁移脚本：

alembic revision --autogenerate -m "add indexes to orders"

这句话的意思是让Alembic对比当前数据库状态和模型定义，自动生成变更脚本。然后检查生成的迁移文件：

alembic upgrade head

在跑迁移之前，有一个问题必须注意：大表加索引会锁表。MySQL 8.0之前的版本，ADD INDEX会使用INPLACE算法，但仍有锁的窗口期。线上如果是一张亿级表，直接在业务高峰期执行ALTER TABLE ADD INDEX，轻则慢查询堆积，重则主从延迟持续十几分钟。

一个安全的做法是分阶段执行。先创建新表加索引，再通过数据同步手段把数据迁过去，最后切换表名。或者至少在低峰期执行，并使用ALGORITHM=INPLACE, LOCK=NONE显式声明：

ALTER TABLE orders ADD INDEX idx_user_created (user_id, created_at), ALGORITHM=INPLACE, LOCK=NONE;

注意：LOCK=NONE并不等于完全无锁，它只代表允许并发读写，但在操作的某个短窗口内仍然需要元数据锁。对大表的任何结构变更，都应该先在一个从库或预发环境做演练，确认耗时再上生产。

3.3 FastAPI侧如何“喂饱”索引：写出能让索引生效的查询

模型和索引都建好了，如果业务代码里写SQL的方式不对，索引照样形同虚设。我在FastAPI项目中总结了三个最常见的“索引杀手”，全部踩过坑。

杀手一：对索引字段做函数运算。比如WHERE DATE(created_at) = '2024-01-01'，MySQL对created_at做了一次DATED函数转换，索引就废了。正确写法是范围查询：WHERE created_at >= '2024-01-01 00:00:00' AND created_at < '2024-01-02 00:00:00'。

杀手二：前模糊匹配。WHERE name LIKE '%张三%'，百分号在最前面，B+Tree的正序链表没法用，索引失效。如果确实要做包含查询，要么考虑全文索引，要么在应用层拆词。如果只是前缀匹配LIKE '张三%'，那索引是可以用的。

杀手三：隐式类型转换。字段是字符串，传进来的是int，MySQL会先把字段转成数字再比较，索引作废。WHERE phone = 13800138000这种情况，phone是varchar，传了int，MySQL做完转换后索引直接失效。FastAPI里Pydantic校验一遍之后，类型不匹配的请求早就被拦下了，所以很少踩这个坑——但如果是手写原生SQL、或者从外部系统拼接条件查询，就得特别小心。

在SQLAlchemy里写查询时，保持类型一致也很重要：

from sqlalchemy import select from sqlalchemy.orm import Session def get_user_orders(db: Session, user_id: int, start: str, end: str): stmt = ( select(Order) .where(Order.user_id == user_id) .where(Order.created_at >= start) .where(Order.created_at < end) .order_by(Order.created_at.desc()) ) return db.execute(stmt).scalars().all()

这个查询用上了idx_user_created联合索引，user_id做等值定位，created_at做范围遍历，排序也直接走索引的有序性，连ORDER BY额外排序都省了。

4. 索引优化的关键决策：什么时候建、什么时候拆、什么时候忽略

4.1 联合索引到底建几个：一个常见设计套路

联合索引是索引优化的“主战场”。它有效，但代价也高——每个索引都是一棵独立的B+Tree，写入时都要同步维护。索引建得越多，写入越慢、存储越大。所以设计联合索引的总原则是：尽量用少数几个联合索引覆盖尽量多的查询模式。

给你一个真实场景。一张订单表，业务方最常用的查询是：

SELECT * FROM orders WHERE user_id = ? AND status = ? ORDER BY created_at DESC;

这时候建索引(user_id, status, created_at)一条就够了：user_id定用户，status定状态，created_at做排序。这个索引同时还能覆盖：

• 仅按user_id查
• 按user_id + status查
• 按user_id查并按时间排序

但你如果建的顺序是(status, user_id, created_at)，那查询带上user_id但不带status时，最左前缀直接断掉，索引用不上。这就是经常听到的“索引失效”的底层原因。

再看另一种情况：如果业务方还经常单独查询WHERE status = ? AND created_at >= ?，上面的联合索引帮不上忙，因为user_id不在条件里。这时候就需要评估：这种查询多不多？如果只是偶尔跑一次报表，宁可接受全表扫描慢几秒，也不要再白养一个索引。如果频次很高，那就得再建一个(status, created_at)索引。

索引不是越多越好，而是和查询模式对齐才有效。我的习惯是：拿生产环境一周的慢查询日志，找出Top 20条按次数排序的慢SQL，针对每条SQL分析条件字段和排序字段，然后合并同类项，设计出尽量少的一组联合索引。

4.2 覆盖索引：连回表都省掉的进阶玩法

再回到之前提到的回表问题。二级索引叶子节点存的是主键值，查询时如果SELECT的字段全部包含在索引里，MySQL根本不需要回表找完整数据行，这叫覆盖索引，是查询优化里性价比极高的一招。

举个例子。列表页常见需求：根据状态分页查订单ID和订单号，然后展示。

SELECT id, order_no FROM orders WHERE status = 'paid' ORDER BY id LIMIT 20 OFFSET 20;

如果只建了status单列索引，每次查询都要从二级索引里拿到主键，再回表到聚簇索引读取order_no字段。但如果建一个(status, order_no)联合索引，这两个字段都在索引页里，整个查询在二级索引的B+Tree里就能完成，不需要任何回表操作。

判断一个查询是不是覆盖索引，最直接的办法是看EXPLAIN结果里的Extra列。如果显示Using index，说明用了覆盖索引；如果显示Using index condition，说明用了ICP（索引下推），也是一种优化手段，但比纯覆盖略弱；如果显示Using where，则说明索引定位之后还要回表去过滤其他字段。

实操心得：开发阶段跑每个查询前，先用SQLAlchemy编译出原生SQL，再复制到数据库客户端里跑EXPLAIN，养成这个习惯之后，几乎不会写出“看起来能走索引实际走不上”的烂查询。

4.3 小表大表分开治理：别为几千行建索引

有一种情况我见过特别多——开发环境表里就几百行，顺手给每个字段都加上index=True，结果生产环境数据量一大，索引膨胀得很厉害。实际上，记录数只有几千行的表，全表扫描比走索引更快。因为InnoDB读一个数据页大约16KB，几千行的表可能在几十个页里，顺序扫描这些页非常快，而走索引反而要额外跳表查询、可能还要回表，多出好几次随机IO。

判断标准很简单：看表大小。单表数据量在十万行以下，除非查询频繁且明显很慢，否则不用刻意加索引。等到数据量上来、慢查询日志开始报警，再针对性地补索引，也为时不晚。

这也回应了“一劳永逸地建好所有索引”这种思维误区——索引设计不是建表时一次性完成的工作，它是一个随着业务增长和数据量变化不断迭代的过程。很多传统项目规划阶段把索引设计得又全又精致，结果大部分索引永远没被用到，写入性能反而被拖慢。真正合理的姿势是：先建主键和唯一约束，让核心查询跑起来，然后听慢查询日志的，让它告诉你下一步应该加什么索引。

5. FastAPI接口性能对比：索引优化前后到底差了多少

5.1 实测：一个普通分页接口的优化全过程

这个例子来自我自己的一个项目。一张orders表，数据量大概120万行，FastAPI提供分页查询接口：

@app.get("/orders") def list_orders(user_id: int, status: str, page: int = 1, page_size: int = 20): offset = (page - 1) * page_size stmt = ( select(Order) .where(Order.user_id == user_id) .where(Order.status == status) .order_by(Order.created_at.desc()) .limit(page_size) .offset(offset) ) result = db.execute(stmt).scalars().all() return result

最初这个查询没有联合索引，只有主键和order_no唯一索引。用EXPLAIN看执行计划：

EXPLAIN SELECT * FROM orders WHERE user_id = 1001 AND status = 'paid' ORDER BY created_at DESC LIMIT 20 OFFSET 20;

结果里type=ALL，rows=1200000，Extra列是Using where; Using filesort。这意味着全表扫描120万行，还要在内存或者磁盘里做文件排序。真实的接口平均响应时间在900ms到1500ms之间，高峰时能到3秒以上。

加了联合索引idx_user_status_created (user_id, status, created_at)之后，再看EXPLAIN：

type=ref, key=idx_user_status_created, rows=52, Extra=Using index condition

执行计划从全表扫描120万行，变成走索引定位52行。再测接口性能：

• 优化前P95响应时间：1260ms
• 优化后P95响应时间：38ms
• 提升幅度接近33倍

整个优化过程只花了两分钟——一条ALTER TABLE加索引，加一个模型里的__table_args__。这就是索引优化的魅力，改动最小，收益最大。

5.2 别忽略EXPLAIN：一张表看懂执行计划的含义

上面的案例里我们提到了type、rows、Extra这几个字段，我给读者整理成一张表，以后看执行计划可以直接对照：

特别提醒一句：Using filesort并不代表真在磁盘上排序了，它只是说索引本身没有提供有序性，MySQL需要在排序阶段额外处理。只要数据和排序缓存够大，这个排序可能在内存里完成，但它依然是性能隐患，因为排序代价会随着结果集变大而急剧上升。避免它的办法很简单：把排序字段设计进联合索引里，让B+Tree天然有序。

5.3 分页深度变大怎么办：OFFSET的陷阱与替代方案

上面的分页接口在页数较小时很完美，但如果你翻到第10000页，也就是OFFSET 200000，即使索引完全生效，MySQL也要先扫过20万条索引记录再丢掉前199980条，只返回最后20条。这是OFFSET分页的天然缺陷。

解决思路有两种。第一种是键集分页（keyset pagination）：不传页码，改传上一页最后一条记录的游标。

@app.get("/orders") def list_orders(user_id: int, status: str, cursor: str = None, page_size: int = 20): stmt = ( select(Order) .where(Order.user_id == user_id) .where(Order.status == status) ) if cursor: stmt = stmt.where(Order.created_at < cursor) stmt = stmt.order_by(Order.created_at.desc()).limit(page_size + 1) result = db.execute(stmt).scalars().all() # 根据返回条数判断是否还有下一页 has_next = len(result) > page_size return {"items": result[:page_size], "has_next": has_next}

这种写法天然走索引，并且每次查询只扫描page_size条记录，不管翻多深，性能恒定。缺点是不能再随意跳页，但从用户习惯来看，很多高频分页场景根本不关心跳页，只关心“下一页”。

第二种是延迟关联：先只查主键id，再跟全表关联取数据。这样即使OFFSET很大，二级索引扫描的是小字段，回表数量被压缩到最小：

subq = ( select(Order.id) .where(Order.user_id == user_id) .where(Order.status == status) .order_by(Order.created_at.desc()) .limit(page_size) .offset(offset) .subquery() ) stmt = ( select(Order) .join(subq, Order.id == subq.c.id) .order_by(Order.created_at.desc()) )

两种方案各有用武之地：键集分页适合“下一页”模式的App接口，延迟关联适合后台管理系统里的跳页排序表格。

6. 慢查询排查实录：三个真实案例

6.1 ORM的懒加载，查询放大效应

第一个案例很有代表性。FastAPI接口里查询订单列表，然后直接返回给前端。看起来只查了一次orders表，但SQLAlchemy的relationship默认懒加载，序列化时会逐条再去查关联的user表、order_items表。

N+1次查询就这么产生了。100条订单，每条触发两次关联查询，一共201次SQL。索引建得再漂亮，架不住查询次数爆炸。解决办法是查询时用joinedload一次性JOIN出来：

from sqlalchemy.orm import joinedload stmt = ( select(Order) .options(joinedload(Order.user), joinedload(Order.items)) .where(Order.user_id == user_id) .order_by(Order.created_at.desc()) .limit(20) )

或者只取需要序列化的字段，用上前面说的覆盖索引，避免整个行数据的读取。排查方法也简单：把SQLAlchemy的echo=True打开，看日志里一个请求到底发出了多少条SQL。这个习惯值得保持到生产环境出问题之前。

6.2 隐式类型转换把唯一索引弄失效了

第二个案例来自一个用户导出功能。FastAPI接口接收一个Excel里的手机号列表，然后批量查询用户信息。

phones = ["13800138000", "13900139000"] stmt = select(User).where(User.phone.in_(phones))

看起来没毛病。结果这个查询跑了快点几秒。回到数据库EXPLAIN一看，type=ALL，索引没用上。查了字段定义才发现，phone是varchar(11)，但批量导入的时候数据源把手机号变成了整数，列表里全是int类型。MySQL在做IN查询时，发现字段类型和值类型不一致，自动做了隐式转换，索引直接失效。

解决方式很粗暴但有效：在Pydantic层把输入强制转成字符串：

from pydantic import BaseModel class PhoneExportRequest(BaseModel): phones: list[str] @field_validator("phones") @classmethod def normalize_phones(cls, v): return [str(p) for p in v]

这个案例特别值得记住：索引失效很多时候不是索引的问题，是查询参数和字段定义不匹配。遇到慢查询，先别急着加索引，看看字段类型和条件值是否一致。

6.3 字符串日期比较的坑

第三个案例是关于DateTime字段的。某次优化后，我把查询条件从“函数包裹字段”改成了范围比较，性能恢复了，但后来发现新需求里用了ISO格式的字符串来做比较：

stmt = select(Order).where(Order.created_at >= "2024-06-01T00:00:00")

这一次索引倒是用上了。但小心，MySQL在字符串与datetime比较时会发生隐式类型转换，依然存在无法使用索引的情况。测试下来，上面的SQL能走索引，因为MySQL这个版本里会尝试把字符串按照时间格式解析。但如果你传递的字符串格式混乱，MySQL不得不把字段转成字符串来比较，索引就会失效。

规矩其实很简单：在应用层就把时间统一成datetime对象，永远不要原生SQL里做字符串日期直接比。在FastAPI里，配合Pydantic对整个请求做校验和解析，这一步很容易就能做到。

from datetime import datetime from pydantic import BaseModel, Field class OrderQueryParams(BaseModel): start: datetime | None = None end: datetime | None = None

数据进到视图函数之前，已经被Pydantic解析成了datetime对象，查询时就能保证类型准确匹配。

7. FastAPI项目索引优化的完整流程与工具链

7.1 推荐命令行与SQL工具组合

平时在FastAPI项目里做索引排查，我最常用的工具是这一套组合：

• EXPLAIN：分析单条SQL执行计划
• SHOW PROFILE：查看SQL在MySQL内部各个阶段的耗时
• performance_schema：查看事件级别的等待和锁信息
• pt-query-digest：分析慢查询日志，统计Top SQL

排查思路按照顺序来：先开慢查询日志，slow_query_log=ON，long_query_time=1，跑上半天或一天，把Top慢查询挑出来。然后用EXPLAIN逐个分析执行计划，找出type=ALL或者rows异常高的查询，针对性地补索引。补完索引之后再跑同一批测试SQL，对比耗时和rows变化。

这套流程最适合FastAPI这类以CRUD为主的后端项目，因为大部分慢查询都是同一个模式：条件字段上没有索引，或者有索引但因为写法问题用不上。

7.2 一个可以直接用的Alembic迁移模板

再给你一个可以直接抄的迁移模板。假设你的订单表要新增两个索引，之前没有建过，迁移脚本长这样：

"""add indexes to orders Revision ID: 3f2b8c1d9a42 """ from alembic import op import sqlalchemy as sa revision = "3f2b8c1d9a42" down_revision = "1a2b3c4d5e6f" branch_labels = None depends_on = None def upgrade() -> None: op.create_index("idx_user_created", "orders", ["user_id", "created_at"]) op.create_index("idx_user_status_created", "orders", ["user_id", "status", "created_at"]) def downgrade() -> None: op.drop_index("idx_user_created", table_name="orders") op.drop_index("idx_user_status_created", table_name="orders")

为了生产环境大表安全，升级前先评估表大小。表超过100万行，建议先跑一个测试脚本估算耗时，或者在低峰期执行。

注意：downgrade里的drop_index看起来很简单，但生产环境的回滚比升级更危险。一旦回滚把索引删了，查询直接回到全表扫描状态，线上请求会瞬间打垮数据库。所以执行回滚前务必在有流量的预发环境演练一遍。

7.3 索引监控：如何知道索引“有没有被用到”

索引加完之后，别急着以为万事大吉。MySQL的performance_schema里记录着每个索引的使用统计，可以通过以下查询检查哪些索引从未被请求过：

SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT_STAR FROM performance_schema.table_io_waits_summary_by_index_usage WHERE OBJECT_SCHEMA = 'fastapi_app' AND COUNT_STAR = 0 AND INDEX_NAME IS NOT NULL ORDER BY OBJECT_NAME;

看到长时间COUNT_STAR = 0的索引，说明它建完之后从没有被任何查询用到。这种索引就是纯消耗品：拖慢写入、占用存储。高并发写入的场景下，没被用到的索引最好及时清掉，但清之前必须确认它真的没有被依赖，比如某些查询可能因为数据量少恰好走了更优的路径，不代表这个索引毫无意义。

这一点挺考验经验的：一个索引有没有用，不能只看“当前是否命中”，要看“将来某个数据分布场景下是否会用到”。我的原则是：观察期至少两周，包含一次完整的业务高峰，如果那段时间依然零命中，再考虑删除。

8. FastAPI与数据库索引的协同设计：在框架层还能做什么

8.1 异步查询不要忘了连接池上限

FastAPI的async特性很容易让人误以为“异步=无限并发”。其实瓶颈在数据库连接池。SQLAlchemy异步模式配的是asyncpg驱动，默认连接池大小可能是5或10个。如果FastAPI的worker一多，同时涌进来的请求一多，数据库连接池瞬间被打满，请求排队等待连接，接口延迟会急剧上升。

索引优化解决的是“查询本身慢”的问题，连接池管理解决的是“并发太多挤不上”的问题。两者叠加，才能让接口又快又稳。一个经验配置：

from sqlalchemy.ext.asyncio import create_async_engine engine = create_async_engine( "postgresql+asyncpg://user:password@localhost/fastapi_app", pool_size=20, max_overflow=10, pool_pre_ping=True, )

pool_pre_ping=True这个选项很容易被忽略。它会在每次从连接池取连接时发一个轻量级探测，防止取到已经被数据库断开的死连接。在高并发的FastAPI应用里，这个配置能避免大量“连接已失效”的诡异报错。

8.2 统计信息过期了，索引再好也没用

索引优化还有一个容易踩的坑，比索引本身更隐蔽——表的统计信息过期。MySQL优化器选择执行计划时，依赖的是表统计信息估算出来的rows。如果统计信息严重过期，优化器可能判断“走这个索引要扫很多行，还不如全表扫”，于是放弃了本该走索引的查询。

解决办法有几种。手动执行ANALYZE TABLE刷新统计信息：

ANALYZE TABLE orders;

或者开启innodb_stats_auto_recalc，让它自动触发：

SET GLOBAL innodb_stats_auto_recalc = ON;

如果表经常批量更新，统计信息频繁失效，可以考虑增加采样页数，让统计更精确：

SET GLOBAL innodb_stats_persistent_sample_pages = 64;

遇到过一种很诡异的情况：同一个SQL，在测试库走索引秒回，在预发库全表扫描慢得离谱。两边表结构和数据量几乎一样，最后发现就是统计信息差太多。刷新完之后执行计划恢复正常。所以排查顺序别搞反——先看统计信息，再看索引缺失。

8.3 用FastAPI依赖注入统一管理慢SQL监控

最后分享一个小技巧。FastAPI的依赖注入系统非常适合做数据库监控。我之前在自己的FastAPI项目里写了一个简单但实用的SQL执行耗时切面：

import time from sqlalchemy import event from sqlalchemy.engine import Engine import logging logger = logging.getLogger("sqlalchemy.slow") @event.listens_for(Engine, "before_cursor_execute") def before_cursor_execute(conn, cursor, statement, parameters, context, executemany): conn.info.setdefault("query_start_time", []).append(time.perf_counter()) @event.listens_for(Engine, "after_cursor_execute") def after_cursor_execute(conn, cursor, statement, parameters, context, executemany): total = time.perf_counter() - conn.info["query_start_time"].pop() # 超过500ms的SQL记录到慢查询日志 if total > 0.5: logger.warning("Slow SQL %s (%.2fs)", statement, total)

把它放进FastAPI应用的启动逻辑里，每次超过500毫秒的SQL会全部打上慢日志标记。在索引优化之前，先靠它把所有慢查询收集起来，再逐个分析，效果比翻数据库的慢查询日志更直接。

9. 优化完成之后，别忘了做这几件事

索引优化不是“加完索引就收工”。以我自己的项目经验为例，每次做完一轮索引优化，必须紧接着完成三件事。

第一，重新跑全量接口回归测试。你改的是索引，影响的是所有查询路径。一个索引可能会让某个原本走全表扫描的查询改走索引，也可能因为索引选择变化导致执行计划变化，性能未必全部变好。跑一遍核心接口的回归测试，至少保证没有响应时间异常劣化的接口。

第二，把慢查询阈值调低一档。索引优化之前，1秒钟的查询可能不在你的关注范围内。优化完成之后，把long_query_time从1秒调整为200毫秒，你会看到更多“隐性慢查询”——那些没超1秒但仍然很慢的查询，它们在下一次数据量翻倍时就可能变成真正的瓶颈。

第三，写一份索引设计说明文档。我见过太多项目，索引建了一堆，没人知道每个索引是为什么建的。半年后新来的同事看着一堆idx_user_status_xxx无从下手，也不敢删，只能看着存储一点点膨胀。这份文档不一定长篇大论，只要写清楚“哪个索引、覆盖哪些查询、为什么字段顺序是这样”，就能让后面接手的人做出准确的判断。

把这三件事做完，这轮索引优化才算真正闭环了。接下来就是持续迭代——数据量增长、新业务上线、查询模式变化，索引设计也会跟着一起演变。这是一个永远做不完、但是越做越有价值的长期工作。我在实际项目中最大的体会是：索引优化的核心不是“懂多少索引原理”，而是“能不能养成慢查询日志—分析—调整—验证”的循环习惯。工具就摆在那里，能不能把它的价值榨出来，取决于你愿不愿意在每次接口变慢的时候，多花十分钟去看一眼执行计划。