后端性能优化：从数据库到缓存的实战经验
后端性能就像水管的流量，就算服务器配置再高，中间某个环节堵了，用户体验照样拉胯。我见过太多团队把钱砸在高级服务器上，却忽略了代码和架构的“小毛病”。其实性能优化不用一开始就上微服务、分布式，先把基础的数据库和缓存捋顺，80%的问题都能解决。
数据库优化：别让查询成为“ bottleneck”
数据库绝对是后端性能的“重灾区”。之前帮一个社交APP优化时，他们的用户动态列表接口在高峰期能卡到5秒以上，查日志发现一个简单的SELECT FROM posts WHERE user_id = ?居然没加索引！当时我让他们给user_id和created_at建了联合索引，再把SELECT 改成只查需要的字段（比如id,content,created_at），第二天响应时间就降到了0.5秒以内。
索引优化看似基础，但很多人其实没做对。比如盲目给所有字段加索引，结果写入性能暴跌——因为每次插入数据，数据库都要维护多个索引树。正确的做法是先跑EXPLAIN分析慢查询，看看哪些SQL用了“全表扫描”（type字段显示ALL），再针对这些查询的WHERE、JOIN条件建索引。 索引不是一成不变的，用户量增长后，之前的索引可能失效， 每季度用慢查询日志（比如MySQL的slow_query_log）复盘一次。
除了索引，分库分表也是大流量项目的必备技能。但别一上来就分，先试试“垂直分表”——把大表拆成小表，比如用户表拆成user_base（基本信息）和user_details（详细资料），查询登录信息时就不用加载冗余字段。去年做的教育平台，用户表有20多个字段，拆表后单表查询速度提升了40%。如果数据量超过1000万行，再考虑“水平分表”，按用户ID取模或者时间范围分，比如订单表按月份拆成orders_202401、orders_202402，查询时只访问对应月份的表。
缓存策略：用对了能省一半服务器成本
缓存就像给后端装了“加速器”，但用错了反而会帮倒忙。之前有个电商项目，为了提升商品详情页速度，把所有商品数据都丢进Redis，结果缓存满了自动淘汰旧数据，用户频繁看到“商品已下架”（其实还在）。后来才发现他们没设置合理的过期时间，也没做缓存预热——新商品上架后缓存是空的，第一次访问还是查数据库，等于白忙活。
缓存的核心是“热点数据优先”。你得先搞清楚哪些数据访问频率高、变化少，比如首页Banner、商品分类列表，这些适合长期缓存；而用户购物车、实时库存这类频繁变化的数据，缓存时就要小心。我通常会用“缓存+数据库双写”策略：更新数据时先更数据库，再删缓存（别直接更新缓存，避免并发时数据不一致），然后设置较短的过期时间（比如5分钟）兜底。 缓存穿透（查不存在的数据）和缓存雪崩（大量缓存同时失效）也得防，前者可以用布隆过滤器过滤无效Key，后者把缓存过期时间加个随机值（比如1-5分钟），避免“集体失效”。
这里整理了常用的性能优化工具，你可以根据项目情况选：
| 工具类型 | 推荐工具 | 适用场景 | 优势 |
|---|---|---|---|
| 慢查询分析 | Percona Toolkit | MySQL性能瓶颈排查 | 支持批量分析慢日志，生成优化 |
| 缓存监控 | Redis Insight | Redis缓存状态跟踪 | 可视化展示命中率、内存使用，支持告警 |
| 接口性能测试 | JMeter | 高并发场景模拟 | 支持自定义请求参数，生成性能报告 |
用这些工具跑一遍，你会发现很多之前忽略的问题——比如我上次帮一个资讯平台测试，发现他们的热门文章接口在100并发下就开始超时，查了才知道缓存命中率只有60%，优化后提到95%，服务器负载直接降了一半。
后端安全防护：避开90%开发者都会踩的坑
后端安全就像家里的门锁，平时感觉不到重要性，一旦被撬就可能“家破人亡”。去年朋友的创业项目因为没做参数过滤，用户注册接口被注入恶意SQL，整个用户表数据差点被删光，最后花了三天才恢复，还丢了不少用户。其实后端安全不用搞得太复杂，把基础的“门锁”装好，就能挡住大部分攻击。
输入验证：别让用户“喂”给你脏数据
所有从前端来的数据都是“不可信的”——这句话你一定要刻在脑子里。不管用户是正常输入还是恶意攻击，后端都得先过一遍“安检”。之前接过一个外包项目，他们的评论功能直接把用户输入的内容存进数据库，结果有人在评论里写了alert('XSS')，其他用户打开页面就弹框，最后不得不全量清理评论数据。
正确的做法是“过滤+转义”双保险。对字符串类型的参数，用正则表达式过滤特殊字符（比如/[^a-zA-Z0-9u4e00-u9fa5]/g保留常用字符）；存数据库时用参数化查询（比如MySQL的PreparedStatement），别直接拼接SQL——"SELECT FROM users WHERE name = '" + username + "'"这种写法就是在给SQL注入开后门。 数字类型的参数要强制转换，比如用户传id=abc，直接返回错误而不是让程序崩掉。
OWASP（开放Web应用程序安全项目）每年都会发布Top 10安全风险，其中注入攻击（SQL注入、NoSQL注入等）常年排在前三，你可以去他们官网（OWASP Top 10）看看最新的防护指南，里面有详细的案例和代码示例。
API安全：给接口穿上“防弹衣”
API是前后端通信的桥梁，也是攻击者最喜欢“钻空子”的地方。之前帮一个金融APP做审计，发现他们的转账接口居然只用用户ID做身份验证，没有校验token有效期，结果有人抓包改了用户ID，差点转走别人的钱。接口安全至少要做好三件事：身份认证、权限控制、请求限流。
身份认证推荐用JWT（JSON Web Token），但别把敏感信息（比如密码）放进去，而且一定要设置过期时间（exp字段），最好再加个刷新token机制——用户登录后给两个token，access_token短期有效（比如2小时），refresh_token长期有效（比如7天），过期后用refresh_token换新的access_token，避免频繁登录。权限控制可以用RBAC模型（基于角色的访问控制），比如普通用户只能查自己的订单，管理员才能看所有订单，代码里可以加注解@CheckRole("ADMIN")统一拦截。
请求限流也很重要，防止恶意刷接口。你可以用Redis记录每个IP的请求次数，比如ip:192.168.1.1 -> 100，设置1分钟内最多100次请求，超过就返回429状态码。之前有个电商平台的秒杀接口没做限流，活动刚开始就被刷了10万次请求，服务器直接宕机，后来加了限流，配合队列削峰，才算稳住。
其实后端开发就像盖房子，性能是地基，安全是承重墙，两者都得扎实。你不用一下子学完所有技术，先把今天说的数据库索引、缓存策略、输入验证、API安全这几点做好，项目就能稳不少。如果你按这些方法优化了项目，或者遇到了其他问题，欢迎回来留言讨论——毕竟后端这条路，多交流才能少踩坑。
防SQL注入这事儿，参数化查询确实是基础，但光靠它还不够，得搭配其他“小手段”一起用才稳妥。就说输入过滤吧，这招我之前帮一个博客项目处理评论功能时用过——当时他们让用户随便输入，结果有人在评论里写了“1′ OR ‘1’=’1”这种注入语句，差点把整个文章表查出来。后来我给加了层过滤，用正则表达式/[^a-zA-Z0-9u4e00-u9fa5，。！？]/g把特殊符号（像单引号、分号、括号这些）都过滤掉，只留字母、数字、中文和常用标点，评论区一下子干净多了。不过记得别过滤太狠，之前有个项目连用户输入的“%”都滤掉了，结果想搜“90%好评”的商品都搜不出来，用户体验反而变差，所以过滤规则得根据业务调整，“够用就好”。
再说说ORM框架，这简直是懒人福音。我刚开始写后端时，图方便用MyBatis的${}拼接SQL，结果有次做用户登录功能，SELECT FROM users WHERE username = ${username}，被人试了个username='admin' OR '1'='1'，直接把管理员账号查出来了，吓出一身冷汗。后来换成#{} ，框架自动把参数转成预编译语句，就再也没出过这问题。现在主流的ORM框架（像Hibernate、Spring Data JPA）都有这功能，写代码时不用自己操心SQL拼接，既省事儿又安全。不过得注意，有些复杂查询可能还是要用原生SQL，这时候千万别偷懒，老老实实参数化，别给注入留空子。
最小权限原则也得提一嘴，这招能“兜底”。之前帮一个电商项目做安全审计，发现他们查订单用的数据库账号居然有delete权限，当时就惊了——万一被注入个DELETE FROM orders，那不全完了？后来让他们拆成三个账号：查订单用只读账号（只能SELECT），下单用有insert权限的账号，退款用有update权限的账号，每个账号只给“刚好够用”的权限。结果半年后真遇到次注入攻击，对方想删表，因为账号没权限，只返回了个“拒绝访问”，数据一点没丢。OWASP官网也说，输入验证+输出转义+参数化查询是防护注入的“三重保险”，输出转义就是把用户输入的特殊字符转义（比如把<转成<），既防注入又防XSS，这几招结合起来，不用搞多复杂的安全架构，就能挡住90%以上的注入攻击，关键是把基础的“防护网”织密了。
如何快速判断数据库查询是否需要优化？
可以通过两个简单方法初步判断。一是观察接口响应时间，普通业务查询超过500ms就可能存在优化空间；二是用EXPLAIN分析SQL语句，重点看type字段，若显示ALL（全表扫描）或filesort（文件排序），说明查询效率低。比如文章中提到的社交APP案例，通过EXPLAIN发现用户动态列表查询没加索引，优化后响应时间从5秒降到0.5秒，就是典型的“小调整解决大问题”。
缓存命中率多少算正常？低于多少需要优化？
一般来说，缓存命中率保持在90%以上比较合理，低于80%时 排查问题。常见原因包括缓存粒度不合理（比如缓存整个页面而非核心数据）、过期时间设置极端（太短导致频繁失效，太长导致数据不一致）。提高命中率的小技巧：优先缓存热点数据（如首页Banner、高频访问的商品详情），用LRU（最近最少使用）淘汰策略，非实时数据设1-2小时过期，实时数据（如库存）设5-10分钟，既能保证新鲜度又减少缓存穿透。
除了参数化查询，还有哪些防止SQL注入的实用方法？
除了参数化查询（避免直接拼接SQL），这三个方法也很实用：一是输入过滤，用正则表达式保留必要字符（比如只允许字母、数字、中文，过滤单引号、分号等特殊符号），但注意别过度过滤影响正常功能；二是使用ORM框架（如MyBatis、Hibernate），框架会自动处理SQL拼接，降低注入风险；三是最小权限原则，给数据库账号分配“刚好够用”的权限（如查询用只读账号，写入用单独账号），即使被注入也能减少损失。OWASP官网提到，输入验证+输出转义+参数化查询是防护SQL注入的“三重保险”。
JWT和Session，API认证用哪个更好？
没有绝对好坏，得看业务场景。Session适合单体应用，优势是服务端可控（随时能失效），但分布式部署时需要共享Session（如用Redis存储），增加复杂度；JWT适合前后端分离或跨服务场景，无需服务端存储，直接在客户端携带，但缺点是一旦签发无法主动撤销，只能等过期。文章提到的金融APP案例用了JWT，搭配access_token（2小时）+ refresh_token（7天）的组合，既减少登录频率，又通过短有效期降低被盗用风险。如果是中小项目， 优先用JWT，实现简单且适配大多数场景。
