1. 字段过多，接口每次都“超重”响应
在一个项目中，我们发现一个接口读取了整张产品表的所有字段，而页面实际上只需要产品名、价格、缩略图。冗余字段包括库存记录、内部标记、管理员备注等，光 JSON 响应就 800KB。
优化方式：
在接口中用字段白名单过滤输出；
前后端约定必要字段，避免全字段返回；
为接口建立专用轻量数据视图。
响应体缩小 86%，接口耗时从 750ms 降为 112ms。
2. 缺乏联合索引，分页变成全表扫描
很多人分页用 limit offset 语法，数据一多后每次翻页都重新从头遍历。
解决方式：
为分页主字段（如时间戳、ID）建立索引；
使用
where id < last_id+limit N替代 offset；尽量避免子查询嵌套分页，性能会指数下降。
优化后，分页响应速度从 1.8 秒提升到 300ms。
3. 数据冗余 + 表关联混乱，拖垮响应速度
我们遇到一个官网后台，请求首页推荐产品时同时 join 了 6 张表，包括用户收藏记录、价格历史、品类标签等，查询逻辑复杂、执行计划庞大，拖慢整页加载。
优化方式：
首页推荐使用 Redis 做短期缓存；
结构复杂内容预先生成中间表，定期更新；
用户行为数据异步加载，非首屏展示。
整体页面首屏加载从 4.6 秒压缩至 1.1 秒。
数据库不是只存数据，它决定了数据能否快速提取
很多企业在网站初期结构随便设，结果几年后累积几十万条数据，接口查询卡顿频发、报表生成超时，所有页面都“看起来没问题，但就是慢”。
网站优化不能只盯前端，
数据库结构，才是速度的地基。
