-
一个用 LIMIT offset 做分页的接口,翻到第几万页时一条查询要跑十几秒,把数据库拖垮:一次深分页性能的深度复盘与游标分页正解
列表接口用最常规的 LIMIT offset 分页,前几页飞快,可爬虫脚本一页页翻到第 5 万页时,同样查 20 条却要十几秒、数据库 CPU 打满。根因是 LIMIT 1000000,20 并不是直接跳到第 100 万行,而是从头扫描出前 1000020 行、丢弃前 100 万行只返回 20 行,代价随 offset 线性增长,SELECT * 还要百万次回表。本文讲透 LIMIT offset…- 0
- 0
-
PostgreSQL 索引调优完全指南:从一次"加了一堆索引反而更慢"看懂为什么 B-tree 不是万能的
2023 年我负责一个内部数据平台底层用 PostgreSQL 库里几张核心表都过亿行业务跑了半年一切都还稳直到运营某天上线一个新功能要按用户加时间段加状态组合查订单单次查询时间从 200 毫秒涨到了 12 秒慢查询日志一片红我盯着那几条 SQL 心里很笃定加个索引就完事了于是我对着 where 条件几乎每个字段都建了一个 B 树索引以为这下稳了可等真上线一串问题冒了出来第一种最先把我打懵索引建完…- 0
- 0
-
数据库分区表完全指南:从一次"分了区查询却没变快"看懂为什么分区键才是根本
2022 年我接手一个订单系统的查询优化核心是一张 orders 表几年下来积了好几亿行各种按时间范围查订单的页面越来越慢慢的甚至要十几秒有人提醒我这么大的表该上分区表了第一版我做得很顺手我把 orders 表改造成按 order_id 取模分成 16 个分区心想几亿行的大表被拆成 16 份每份只剩两千多万行查询要扫的数据少了十几倍这查询不就快了嘛可改造上线之后一串问题冒了出来第一种最先把我打懵表…- 0
- 0
查询优化
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×