FastAPI接口变慢？数据库索引优化从原理到实战全指南

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默认用BTree组织相当于给数据建了一棵“目录树”。从根节点到叶子节点走的是二分查找的路子三层BTree就能覆盖上千万条记录。也就是说在一张几千万行的表里做一次点查询走索引只需要读三四个数据页耗时从“秒级”直接降到“毫秒级”。所以判断一个接口慢不慢先别看代码先看你的SQL到底在“翻书”还是在“查目录”。2.2 BTree索引为什么数据库不选二叉树、不选哈希表可能有人会问哈希表不是更快吗O(1)复杂度比BTree的O(logN)好多了。哈希索引确实存在但只适用于等值查询。一旦遇到范围查询、ORDER BY、GROUP BY、模糊匹配哈希就完全帮不上忙。一棵红黑树或AVL树虽然可以做范围查询但树的高度随数据量增长太快几百万条记录就得好几十层高而BTree因为每个节点能存大量键值深度很浅三层基本够用。BTree还有一个杀手级特性叶子结点之间通过双向指针串成链表。这意味着范围查询只需要找到起点然后沿着链表的指针顺序往下拎就行了不需要每次都从根节点重新遍历。这是BTree相比于B-Tree的重大改进也是InnoDB选择它作为默认索引结构的关键原因。提示面试和实际排查中“为什么用BTree”是一个高频问题但真正指导实践的点在于——当你设计索引时要优先考虑等值查询范围查询的组合场景这正是BTree最擅长的事。2.3 聚簇索引和非聚簇索引一次回表等于一次随机IOInnoDB的数据本身就按照主键组织成了一棵BTree这叫聚簇索引。表里的每行数据都挂在主键索引的叶子节点上。除了主键之外的索引都叫二级索引非聚簇索引它们的叶子节点存的不是完整行数据而是主键值。这两者一结合就带出了索引优化最重要的一个概念——回表。比如你在name字段上建了索引执行SELECT * FROM user WHERE name 张三时过程是先去name索引的BTree里找到张三对应的主键id然后再拿着这个id去主键索引的BTree里找完整行数据。第一次查询走了索引很快第二次按主键查询也很快。问题在于这两次是两次独立的BTree检索回表本质上等于多了一次随机IO。数据量大、并发高的时候回表的代价会被放大。那么优化方向就变得清晰了要么让二级索引覆盖所有需要的字段省掉回表这一步这叫覆盖索引要么把索引设计得更精准减少不必要的回表次数。3. FastAPI项目中的索引实战从ORM定义到迁移落地3.1 在Model里定义索引的正确姿势FastAPI本身不管数据库ORM用的最多的是SQLAlchemy。定义索引有两种方式。第一种是直接在字段上声明indexTrue适合单列索引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_keyTrue, autoincrementTrue) name Column(String(64), nullableFalse, indexTrue) email Column(String(128), nullableFalse, uniqueTrue) created_at Column(DateTime, server_defaultfunc.now())uniqueTrue本身就会创建唯一索引所以email字段虽然没写indexTrue查询时依然走索引。如果某个字段既要加速查询又要保证唯一性直接用uniqueTrue就够了。第二种方式是在__table_args__里声明联合索引class Order(Base): __tablename__ orders id Column(BigInteger, primary_keyTrue, autoincrementTrue) user_id Column(BigInteger, nullableFalse) status Column(String(20), nullableFalse, defaultpending) order_no Column(String(64), nullableFalse, uniqueTrue) created_at Column(DateTime, server_defaultfunc.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指向你的Basefrom your_models_module import Base from sqlalchemy import create_engine DATABASE_URL mysqlpymysql://user:passwordlocalhost/fastapi_app?charsetutf8mb4 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轻则慢查询堆积重则主从延迟持续十几分钟。一个安全的做法是分阶段执行。先创建新表加索引再通过数据同步手段把数据迁过去最后切换表名。或者至少在低峰期执行并使用ALGORITHMINPLACE, LOCKNONE显式声明ALTER TABLE orders ADD INDEX idx_user_created (user_id, created_at), ALGORITHMINPLACE, LOCKNONE;注意LOCKNONE并不等于完全无锁它只代表允许并发读写但在操作的某个短窗口内仍然需要元数据锁。对大表的任何结构变更都应该先在一个从库或预发环境做演练确认耗时再上生产。3.3 FastAPI侧如何“喂饱”索引写出能让索引生效的查询模型和索引都建好了如果业务代码里写SQL的方式不对索引照样形同虚设。我在FastAPI项目中总结了三个最常见的“索引杀手”全部踩过坑。杀手一对索引字段做函数运算。比如WHERE DATE(created_at) 2024-01-01MySQL对created_at做了一次DATED函数转换索引就废了。正确写法是范围查询WHERE created_at 2024-01-01 00:00:00 AND created_at 2024-01-02 00:00:00。杀手二前模糊匹配。WHERE name LIKE %张三%百分号在最前面BTree的正序链表没法用索引失效。如果确实要做包含查询要么考虑全文索引要么在应用层拆词。如果只是前缀匹配LIKE 张三%那索引是可以用的。杀手三隐式类型转换。字段是字符串传进来的是intMySQL会先把字段转成数字再比较索引作废。WHERE phone 13800138000这种情况phone是varchar传了intMySQL做完转换后索引直接失效。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 联合索引到底建几个一个常见设计套路联合索引是索引优化的“主战场”。它有效但代价也高——每个索引都是一棵独立的BTree写入时都要同步维护。索引建得越多写入越慢、存储越大。所以设计联合索引的总原则是尽量用少数几个联合索引覆盖尽量多的查询模式。给你一个真实场景。一张订单表业务方最常用的查询是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)联合索引这两个字段都在索引页里整个查询在二级索引的BTree里就能完成不需要任何回表操作。判断一个查询是不是覆盖索引最直接的办法是看EXPLAIN结果里的Extra列。如果显示Using index说明用了覆盖索引如果显示Using index condition说明用了ICP索引下推也是一种优化手段但比纯覆盖略弱如果显示Using where则说明索引定位之后还要回表去过滤其他字段。实操心得开发阶段跑每个查询前先用SQLAlchemy编译出原生SQL再复制到数据库客户端里跑EXPLAIN养成这个习惯之后几乎不会写出“看起来能走索引实际走不上”的烂查询。4.3 小表大表分开治理别为几千行建索引有一种情况我见过特别多——开发环境表里就几百行顺手给每个字段都加上indexTrue结果生产环境数据量一大索引膨胀得很厉害。实际上记录数只有几千行的表全表扫描比走索引更快。因为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;结果里typeALLrows1200000Extra列是Using where; Using filesort。这意味着全表扫描120万行还要在内存或者磁盘里做文件排序。真实的接口平均响应时间在900ms到1500ms之间高峰时能到3秒以上。加了联合索引idx_user_status_created (user_id, status, created_at)之后再看EXPLAINtyperef, keyidx_user_status_created, rows52, ExtraUsing index condition执行计划从全表扫描120万行变成走索引定位52行。再测接口性能优化前P95响应时间1260ms优化后P95响应时间38ms提升幅度接近33倍整个优化过程只花了两分钟——一条ALTER TABLE加索引加一个模型里的__table_args__。这就是索引优化的魅力改动最小收益最大。5.2 别忽略EXPLAIN一张表看懂执行计划的含义上面的案例里我们提到了type、rows、Extra这几个字段我给读者整理成一张表以后看执行计划可以直接对照关键项含义好的表现坏的表现type访问类型const、ref、rangeALL全表扫描key实际用到的索引有索引名NULL没走索引rows预估扫描行数越小越好百万甚至千万级Extra附加信息Using index覆盖索引Using filesort、Using temporary特别提醒一句Using filesort并不代表真在磁盘上排序了它只是说索引本身没有提供有序性MySQL需要在排序阶段额外处理。只要数据和排序缓存够大这个排序可能在内存里完成但它依然是性能隐患因为排序代价会随着结果集变大而急剧上升。避免它的办法很简单把排序字段设计进联合索引里让BTree天然有序。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表。N1次查询就这么产生了。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的echoTrue打开看日志里一个请求到底发出了多少条SQL。这个习惯值得保持到生产环境出问题之前。6.2 隐式类型转换把唯一索引弄失效了第二个案例来自一个用户导出功能。FastAPI接口接收一个Excel里的手机号列表然后批量查询用户信息。phones [13800138000, 13900139000] stmt select(User).where(User.phone.in_(phones))看起来没毛病。结果这个查询跑了快点几秒。回到数据库EXPLAIN一看typeALL索引没用上。查了字段定义才发现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_logONlong_query_time1跑上半天或一天把Top慢查询挑出来。然后用EXPLAIN逐个分析执行计划找出typeALL或者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_nameorders) op.drop_index(idx_user_status_created, table_nameorders)为了生产环境大表安全升级前先评估表大小。表超过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( postgresqlasyncpg://user:passwordlocalhost/fastapi_app, pool_size20, max_overflow10, pool_pre_pingTrue, )pool_pre_pingTrue这个选项很容易被忽略。它会在每次从连接池取连接时发一个轻量级探测防止取到已经被数据库断开的死连接。在高并发的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无从下手也不敢删只能看着存储一点点膨胀。这份文档不一定长篇大论只要写清楚“哪个索引、覆盖哪些查询、为什么字段顺序是这样”就能让后面接手的人做出准确的判断。把这三件事做完这轮索引优化才算真正闭环了。接下来就是持续迭代——数据量增长、新业务上线、查询模式变化索引设计也会跟着一起演变。这是一个永远做不完、但是越做越有价值的长期工作。我在实际项目中最大的体会是索引优化的核心不是“懂多少索引原理”而是“能不能养成慢查询日志—分析—调整—验证”的循环习惯。工具就摆在那里能不能把它的价值榨出来取决于你愿不愿意在每次接口变慢的时候多花十分钟去看一眼执行计划。