后端api能承载的QPS少，我总结出了20个性能问题。

1. 全局锁。
2. 无本地缓存，无Redis缓存。
3. 无MQ削峰。
4. 表设计没优化，没有做字段冗余，查询中大量实时函数计算（字符串截取、日期运算），未提前冗余存储计算结果。
5. 开启了全局事务，全部 insert、delete、update操作都用了事务，事务粒度大。
6. 更新条件范围过大、无索引，行锁升级为表锁。
7. ORM（EF core）开启了实体追踪（没有加AsNoTracking()方法）。
8. 没做分页查询，查询全表数据。
9. limit offset 超大分页，limit 100000,20 扫描前面十万行数据，CPU、IO 暴涨。
10. 查询全部字段，没有按需查找部分字段，有回表查询。
11. 导航属性查询子表，子表数据太多。
12. 多表left join。
13. where条件复杂。
14. sql语句复杂（order by /group by 无索引，in查询扫描行数过大，select distinct 大量去重）。
15. 没命中索引，未建立覆盖索引，必然回表。
16. N+1 查询，导航属性加重此问题，查100条主表记录，循环查询100次子表。
17. 主键用的字符串类型或uuid类型，没用long类型，分页不能按主键排序。
18. 索引列有大量null值，导致复合索引失效。
19. 索引外键过多，每次写入校验约束，阻塞写入吞吐。
20. 缺少分库分表，单表数据量千万级以上不分表，所有业务读写挤压同一张表，索引失效、扫描量大。
21. 无分区表，日志、流水类大表未按时间分区，查询只能全表扫描。
22. like '%查询字符串%' 不会走索引，但是前缀匹配： like '查询字符串%' 会走索引
23. 范围查询，只有左边的范围会走索引，右边的范围及后续条件不会走索引，
      and price >= 100 and price <500 and status=1，只有and price >= 100会走索引， and price <500 and status=1 不会走索引。
      and createTime >='2026-07-01' and createTime < '2026-08-01' and status=1，只有and createTime >='2026-07-01'会走索引，and createTime < '2026-08-01' and status=1 不会走索引。