后端性能优化的核心策略
数据库查询是后端性能的常见瓶颈。使用EXPLAIN分析慢查询，发现全表扫描时，记得添加复合索引。但别过度索引，每个额外索引都会增加写入开销。JOIN操作超过3个表时，考虑拆分成单表查询，用程序内存做关联。
缓存机制要分层设计：
注意缓存雪崩问题，设置随机过期时间很关键。
| 优化手段 | 性能提升 | 实现成本 |
|---|---|---|
| Nginx动静分离 | 40-60% | 低 |
| 数据库分库分表 | 70-90% | 高 |
安全防护的代码级实践
参数校验要贯穿整个调用链。Spring Validation的@Validated注解只是基础，对于复杂业务规则，需要自定义校验器。特别注意金额类参数必须用BigDecimal，避免浮点精度问题。
SQL注入防护有三重保障：
敏感数据加密要注意：
微服务架构的源码设计
接口定义遵循RESTful规范时，版本控制通过URL路径实现更直观。比如/api/v1/users比放在Header里更易维护。服务间调用推荐FeignClient，但要注意：
分布式事务的代码实现中，Saga模式比TCC更适用于长事务。每个参与服务都要实现补偿接口，补偿逻辑必须保证等幂性。 补偿操作记录到专门的事务日志表。
数据库查询慢的时候，先别急着加索引，得用EXPLAIN好好看看执行计划。重点关注type列是不是出现了ALL这种全表扫描的情况，还有rows列显示的扫描行数是不是明显超出预期。比如一个用户表才1万条数据，但某个查询居然扫描了8000行，这肯定有问题。这时候就该看看查询条件里用到的字段，特别是那些经常出现在WHERE、JOIN和ORDER BY里的字段，给它们建个联合索引效果会立竿见影。
不过索引也不是越多越好，每个额外的索引都会拖慢写入速度。一般来说，单个表的索引数量最好控制在5-8个之间，再多的话INSERT和UPDATE操作就会明显变慢。而且建索引也得讲究策略，比如用户表的手机号字段经常用来查询，但如果是加密存储的，直接建索引效果可能不好，这时候可以考虑建个前缀索引。还有那些区分度很低的字段，比如性别这种只有男女两种值的，单独建索引基本没啥用，不如和其他字段一起建复合索引。
常见问题解答
如何判断数据库是否需要添加索引？
通过EXPLAIN分析慢查询日志，关注type列出现ALL（全表扫描）或rows列数值过大的查询。对于WHERE条件中的高频字段、JOIN关联字段和ORDER BY字段， 创建复合索引。但要注意单个表的索引数量控制在5-8个以内，避免影响写入性能。
缓存穿透和缓存雪崩有什么区别？
缓存穿透是指查询不存在的数据（如非法ID），导致请求直接打到数据库，解决方案是缓存空对象或使用布隆过滤器。缓存雪崩是指大量缓存同时失效引发数据库瞬时压力，可通过设置5-30分钟的随机过期时间来避免，并配合熔断机制保护数据库。
为什么金额计算必须用BigDecimal？
float和double采用二进制浮点运算，在处理0.1这类十进制小数时会产生精度丢失（如0.1+0.2=0.30000000000000004）。BigDecimal采用十进制运算，特别适合金融场景，初始化时必须使用String构造器，避免直接传double值。
微服务接口版本控制哪种方式更好？
URL路径版本（/v1/api）适合快速迭代的前期项目，Header版本（Accept: version=1.0）更利于API网关统一管理。 用户量在10万以下的应用采用URL版本，超过50万用户量的复杂系统 使用Header版本配合API网关。
分布式事务补偿机制如何保证幂等性？
每个补偿操作需要记录事务ID+操作类型组成的唯一键，在补偿前先查询事务日志表。 采用”预检-执行-确认”三步流程，配合数据库乐观锁（version字段）或Redis分布式锁，确保补偿操作最多执行一次。
