21 篇博文 含有标签「性能优化」

商品列表一旦开始承载搜索、分类、品牌、价格区间和上下架状态，索引策略就会马上变成瓶颈。很多系统前期会本能地给几个常用字段都加索引，但到了真实查询组合场景里，效果常常并不理想。

发布时间：2024-07-30
作者：一介布衣
标签：Feathers.js, Sequelize, 高级查询, 性能优化, 事务

发布时间：2024-04-01
作者：一介布衣
标签：Sequelize, 原生SQL, 复杂查询, 性能优化

发布时间：2024-03-18
作者：一介布衣
标签：Sequelize, 性能优化, 数据库优化, 查询优化

发布时间：2024-01-15
作者：一介布衣
标签：Sequelize, 数据库连接, 连接池, 性能优化

RAG 缓存层 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 每次都全链路重跑检索和生成，高频场景的成本和延迟会持续被放大，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。

只要页面里有中大型列表，性能问题迟早会出现。很多人这时会本能地去加 memo、useMemo、useCallback，但我越来越觉得，真正决定列表是否好维护的，往往不是有没有做缓存，而是渲染边界有没有拆清楚。

React 18 的并发能力第一次接触时最容易让人兴奋，但真正写进业务后，我觉得最难的不是 startTransition 这个 API，而是你到底知不知道哪些更新应该立刻响应，哪些更新可以稍微“让一下”。

后台列表的分页性能，前期常常给人一种“问题不大”的错觉。因为数据量小时，任何写法都像能跑。一旦线上数据变多，再叠加排序、过滤和关联，分页接口很快就会成为慢查询集中地。

做内容后台时，列表接口很容易越做越贪心：想把作者名、分类、标签、审核状态、最近操作人一次全带出来。Sequelize 的 include 看上去正好可以满足这种愿望，但到了 2021 年，很多团队也已经踩出经验了，这条路要克制。