FastAPI 凭借 Starlette/ASGI 的异步内核与 Pydantic 的类型体系，成为当下 Python Web 开发的高性能代名词。但"异步框架"并不等于"自动变快"——我在多个生产项目中见过同一套代码在压测下从"宣称的几万 QPS"掉到几百，原因几乎都集中在三类：异步路由里混入了同步阻塞调用、依赖注入被滥用成"隐藏的同步耗时点"、以及部署层连接池与进程模型配置错误。本文不重复官方文档的 API 介绍，而是以真实生产事故为线索，把调优思路、参数依据和排查方法讲透。

一、先建立正确的性能观：瓶颈从来不在框架

一、为什么连接池不是"池化一个对象"这么简单

很多工程师把连接池当成一个"预先 new 好一批 Connection，用完放回去"的简单缓存。这种理解在低并发下不会出错，但一旦压测或大促，问题就会集中爆发：连接耗尽、线程阻塞、数据库被打爆、业务雪崩。要理解连接池，首先要理解它管理的"资源"到底贵在哪里。

一个 JDBC 物理连接的开销分三部分：

1. 网络握手：TCP 三次握手 + TLS（如果开启 SSL）+ 数据库协议层的认证交换。内网单次通常 1~3ms，跨机房或云上可达几十毫秒。
2. 服务端会话初始化：MySQL 会为每个连接分配独立线程、独立内存缓冲（sort_buffer_size、join_buffer_size、read_buffer_size 等），还要做权限校验和库表元数据加载。高并发下频繁创建连接等于频繁向服务端索要内存与线程。
3. 连接状态与事务语义：连接是有状态的——当前数据库、事务隔离级别、autocommit、会话变量、临时表、锁等。复用连接时必须"清洗"这些状态，否则就会产生脏数据或锁泄漏。

很多人对 JVM 的理解停留在"解释执行 + 垃圾回收"的层面，却忽略了真正决定吞吐上限的那一层——即时编译器（JIT Compiler）。HotSpot 之所以能在长时间运行后逼近甚至反超静态编译语言，靠的不是把字节码逐条翻译成机器码这么简单，而是一整套基于运行时反馈的激进优化：分层编译、内联、逃逸分析、标量替换、同步消除。这些优化彼此咬合，任何一环失效都可能让后续优化整条链断裂。

本文不打算把 JIT 讲成教科书，而是从生产排障的视角出发，讲清楚三个问题：这些优化在什么条件下才会发生、如何验证它真的发生了、以及它失效时的典型症状是什么。