系统跑着跑着，TPS（每秒事务处理数）卡在几百上不去，开发急、运维愁，老板还等着看压测报告。别慌，这种情况太常见了，关键是要找准瓶颈在哪。
先看是不是数据库拖了后腿
很多系统的性能天花板都在数据库。比如你用 MySQL，高并发下连接数不够，或者慢查询太多，TPS 肯定上不去。可以先查一下当前的连接数和活跃线程：
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Threads_running';
如果 Threads_running 经常上百，那说明查询堆积了。这时候得看慢日志，找出执行时间长的 SQL。加个索引，可能 TPS 直接翻倍。比如有个订单查询没走 user_id 索引，全表扫描，1000 并发就扛不住。加上索引后，响应从 800ms 降到 20ms，TPS 从 300 跑到 1500。
缓存用到位了吗
不是所有数据都要实时查库。像用户信息、配置项、商品详情这些读多写少的数据，扔进 Redis 几乎是标配。有个项目一开始没上缓存，每次请求都查用户权限，数据库直接被打满。后来把用户角色信息缓存 5 分钟，QPS 没变，但数据库压力降了七成，TPS 自然就上来了。
注意缓存穿透和雪崩问题。可以用布隆过滤器挡掉无效请求，缓存时间加点随机值，别让所有 key 同时失效。
代码里有没有“暗坑”
有时候问题出在代码逻辑。比如一个接口里循环查数据库：
for (int i = 0; i < userList.size(); i++) {
User user = userService.getById(userList.get(i));
// 每次都查一次 DB
}这种写法在小数据量看不出来，一上并发就原形毕露。改成批量查询，一次捞出来，性能提升十倍都不奇怪。
应用服务器配置够吗
Tomcat 默认最大线程数是 200，如果你的接口平均耗时 500ms，那理论最大 TPS 就是 200 / 0.5 = 400。想跑更高，就得调大线程数，或者用异步非阻塞模型。
Spring Boot 项目可以在 application.yml 里调整：
server:
tomcat:
max-threads: 400
min-spare-threads: 50
但线程也不是越多越好，上下文切换开销会增加。真要追求高并发，可以考虑 WebFlux 这种响应式方案。
网络和中间件别忽略
服务之间调用走的是 HTTP，延迟动不动几十毫秒。换成 gRPC，基于 Netty，二进制传输，延迟能压到几毫秒。有个内部系统把 OpenFeign 换成 gRPC 后，跨服务调用耗时降了 60%，整体 TPS 提升明显。
还有消息队列，Kafka 比 RabbitMQ 在吞吐量上强不少，大数据量场景更稳。
最后别忘了压测工具本身
有时候不是系统不行，是压测机先扛不住了。JMeter 单机最多模拟几千线程，再多 CPU 就飘红了。这时候得用分布式压测，多台机器一起打，才能测出真实极限。
TPS 上不去，本质是系统某个环节卡住了。就像早高峰的环路，不一定车多，可能是某个匝道收窄了。逐层排查，从数据库、缓存、代码、配置到网络，找到那个最窄的口，打开它，流量自然就上去了。