后台系统刚上线时点哪都快，用了半年开始卡：列表转圈、导出等到超时、保存按钮点完没反应。多数时候不是服务器该升级了，而是数据量上来后，几个常见问题集中暴露。
一、慢查询与索引
先打开数据库慢查询日志，按耗时排序，找出最慢的几条语句。重点看三件事：大表有没有合适索引、有没有在索引列上做函数或模糊匹配、有没有在循环里反复查库。加索引前确认字段选择性，也要评估写入变慢的代价，别给每个字段都加。
二、列表分页
列表默认查全量、页码很大时用 OFFSET 翻页，越翻越慢。改成固定条数分页或按主键游标翻页；列表只取需要的字段，不要在列表查询里联五六张表；总数统计可以缓存或异步计算。
三、导出
导出几万行时同步生成，会把请求卡住，严重时拖垮整个服务。改成异步任务：提交后后台生成文件，完成后通知下载；限制单次导出条数，超出就分批；给用户进度提示，避免重复点击。导出文件也要定期清理，别让存储越积越多。
四、文件存储
图片和附件存在服务器本地，数量和体积上来后，备份变慢、访问也慢。迁到对象存储并加 CDN，数据库只存地址；上传限制大小和类型，图片生成缩略图，不要原图直接展示。
五、日志
日志无限增长会占满磁盘，调试级别日志还会拖慢写入。按天切割、设置保留期、错误日志单独告警；生产环境不要长期开调试日志，敏感信息不要打进日志。
六、前端渲染
表格一次渲染几千行、图片没压缩、同一个接口被多个组件重复调用，页面就会「看起来慢」。用分页或虚拟滚动、合并接口请求、缓存字典数据，先把首屏要展示的内容减下来。
排查顺序
优化前先量化：记录列表加载、导出、保存的耗时，改完用同样的数据量复测。没有基线，就说不清到底有没有变快，也容易被「感觉快了点」带偏。
- 先看监控：CPU、内存、磁盘、数据库连接数，确认瓶颈在哪一层。
- 再看接口耗时：是数据库慢、外部接口慢，还是前端渲染慢。
- 最后优化占比最大的那一项，改完复测，不要一次全改。
如果系统是外部团队开发的，先拿到源码、数据库权限和部署文档，再谈优化；没有这些，只能做表面调整。
另外，缓存和队列能解决不少问题：字典数据缓存、报表异步生成、消息队列削峰。但缓存要设计失效策略，否则用户会看到旧数据，反而更难排查。
