-
列表页前几页飞快、翻到几千页后接口直接超时,我用 LIMIT 一百万逗号二十去查那一页才发现数据库默默扫描并丢弃了前一百万行:一次深度分页 LIMIT offset 性能塌陷的深度复盘
我做了个数据列表页支持翻页,后端分页用最常见的 SELECT * FROM orders ORDER BY id LIMIT offset, size。前几页飞快,可用户翻到很靠后的页(第几千页)接口就慢到超时 500。抓出那条慢 SQL 一看 offset 已到百万级。EXPLAIN 才发现:LIMIT 1000000, 20 不是直接跳到第 1000000 行取 20 条,而是从头扫描并丢弃前…- 2
- 0
-
一个 varchar 手机号字段被用数字去查,MySQL 偷偷做隐式类型转换让索引彻底失效:一次慢查询拖垮数据库的深度排查与类型对齐正解
phone 字段是 varchar 且建了索引,一条 WHERE phone = 13800138000(少了引号,数字)却全表扫描三百多万行、跑了 8 秒、把数据库 CPU 打满。根因是 MySQL 隐式类型转换:字符串和数字比较时,它把字符串列转成数字,等于对每行 phone 做 CAST 运算,索引随之失效。本文从 EXPLAIN 看出 type=ALL/key=NULL 讲起,剖析隐式转换…- 0
- 0
-
我的列表页明明感觉只查了一次数据库,慢查询日志里却冒出几百条 SQL,页面慢得像蜗牛,最后揪出是 ORM 的 N+1 查询在背后疯狂打库的深度复盘
我用 ORM 做订单列表页,查出订单后遍历,用 order.getUser().getName() 显示用户名,代码里只写了一句查询。可页面慢得要命,慢查询日志里竟冒出几百条几乎一样的"按 id 查用户"的 SQL——一条订单对应一条!深究才懂这是经典的 N+1 查询:ORM 懒加载在查订单时没带出 user,直到我在循环里访问 getUser() 才偷偷各发一条 SQL,N …- 0
- 0
-
测试秒回上线却超时:MySQL 索引为何悄悄失效
一条订单查询,开发时毫秒返回,测试环境秒回验收一路绿灯,上线没几周却动辄八九秒甚至超时——而代码和 SQL 一个字都没改。登上服务器一看,CPU、连接数都正常,唯独慢查询日志里它赫然在列;在前面加上 EXPLAIN 才心里咯噔一下:type 是 ALL、rows 几百万、key 那栏空空如也,明明建了索引却压根没走,老老实实把整张表从头扫到尾。真凶经典得让我有点不好意思:字段是 varchar 存…- 0
- 0
-
一条慢 SQL 打满数据库:那些让你索引白建的失效陷阱
一个普通的下午,接口突然集体超时,数据库 CPU 被打满到 100%,而 QPS 看起来一切正常。揪出凶手只用了一条 EXPLAIN——一条平时几毫秒的查询变成了十几秒的全表扫描,明明建了索引却纹丝不动。从那次事故出发,这篇文章把索引失效的六大陷阱、EXPLAIN 怎么读、联合索引最左前缀、覆盖索引、深分页优化到慢查询日志监控,一次讲透。- 3
- 0
-
从应用层手写字符串拼接 SQL 有注入风险 + 每次请求新建连接不复用 + 几乎不建索引查询全表扫描 + 循环里逐条查的 N+1 灾难 + 大事务长时间持锁 + 单库单表硬扛全部读写 + 没有慢查询监控不看执行计划凭感觉优化 古老数据库使用体系 → 2026 参数化预编译彻底防注入 + HikariCP 连接池化复用 + 合理索引与覆盖索引 + 批量查询消灭 N+1 + 清晰事务边界与乐观锁 + 读写分离与分库分表水平扩展 + 慢查询日志加 EXPLAIN 执行计划分析 + Redis 旁路缓存与穿透击穿雪崩防护 现代数据库工程体系 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
12 位 DBA 与后端工程师 87 天把一套跑了七年的粗放数据库使用体系——应用层手写字符串拼接 SQL 随时可能被注入脱库、每次请求新建连接不复用、几乎不建索引查询全表扫描、ORM 在循环里逐条查的 N+1 灾难、一个大事务包住一大堆操作长时间持锁让热点行排队、单库单表硬扛全部读写流量一大主库就 CPU 打满、没有慢查询监控不看执行计划全凭感觉瞎调——用在线 DDL 加双写灰度的稳健方式重构到…- 0
- 0
-
PostgreSQL 性能优化完全指南:从一次"1.2 亿行 orders 表加 30 个索引反而更慢 CPU 95% 高峰打挂"看懂为什么加索引远远不够
2023 年我们接手一个老电商系统的性能优化任务数据库是 PostgreSQL 14 主表 orders 1.2 亿行 products 800 万行 users 500 万行前端反馈商品搜索加订单查询慢到无法忍受 P99 5 秒起步高峰期数据库 CPU 95% 经常被打挂前任 DBA 留下的字典是加索引就行看慢日志哪个表慢就加我们照着做了一周加了 30 多个索引情况非但没好转反而更糟写入变慢磁盘…- 2
- 0
-
PostgreSQL 索引调优完全指南:从一次"500GB CRM 库核心查询 30 秒大客户列表页崩溃"看懂为什么 CREATE INDEX 远远不够
2023 年我们接手一个 SaaS CRM 系统用 PostgreSQL 14 业务起来后客户数据库从 10GB 涨到 500GB 一些核心查询从 50ms 慢慢恶化到 30 秒大客户列表页要等半分钟才出来客户投诉一通接一通我们老板拍板说加索引我们也就加索引这一加发现完全不是 CREATE INDEX 一句话的事加完该慢的还慢不该慢的反而慢了业务直接更崩然后我们陆续踩了一堆坑第一种最让我傻眼我们看…- 0
- 0
-
PostgreSQL 索引设计完全指南:从一次"加 30 个索引写入腰斩查询还是 5 秒"看懂为什么 CREATE INDEX 远远不够
2020 年我接手一个 SaaS 客户关系管理系统 PostgreSQL 15 单库 800 张表最大表 customer_events 8000 万行用户反馈系统越来越慢一个查询从 50ms 涨到 8 秒老板天天追着问我以为加索引嘛简单在 user_id 加个 B-tree 在 created_at 加个 B-tree 在 status 加个 B-tree 一共加了 30 多个索引重启应用查询确…- 0
- 0
-
PostgreSQL 索引与执行计划工程化完全指南:从一次"5 亿行订单表查询走全表扫 8 秒不出"看懂为什么加 B-tree 远远不够
2022 年我们公司有一套核心的订单库跑在 PostgreSQL 上数据量大概 5 亿行单库 30 多张表上线两年一直挺稳定直到某天产品突然要做一个卖家后台的查询页面要支持按订单状态时间范围金额范围客户名称等多个条件组合查询我心想 PostgreSQL 嘛加几个索引就完事顺手在 status time amount 上各加了个 B-tree 索引部署上线第二天卖家中心的接口接连超时业务那边把电话打…- 9
- 0
-
数据库索引失效完全指南:从一次"明明建了索引查询却还是全表扫描"看懂索引为什么没被用上
2023 年我做一个订单管理后台有个最常用的功能是按各种条件查订单按用户查按时间查按状态查数据量一上来这些查询开始变慢怎么让它快起来这件事我没多想就有了方案加索引第一版我做得很顺手查哪个列慢我就给哪个列建一个索引涉及到的列基本都建上了本地拿测试库一测确实快了不少我心里很笃定加索引嘛不就是哪个列查得慢就给哪个列建索引可等数据量再涨查询条件再变复杂一串问题冒了出来第一种最先把我打懵我明明给下单时间列建…- 2
- 0
-
数据库索引完全指南:从一次"加了索引查询还是慢、EXPLAIN 一看根本没走索引"看懂索引优化
2021 年我负责一个订单系统。订单表 orders 已经有几百万行。有个查我的订单的接口越来越慢从几百毫秒一路劣化到好几秒。我看了下它执行的 SQL 是按 user_id 过滤再按 create_time 倒序。我想当然地判断慢无非是没索引加一个就好了。我在 user_id 上建了索引信心满满地上线还是慢。我又想可能 create_time 也得有索引再加一个还是慢。我甚至把 user_id s…- 0
- 0
-
数据库索引完全指南:从一次"明明加了索引、查询还是慢得要命"看懂索引失效
2021 年我做一个订单管理后台。有一个运营天天用的功能:按用户 ID 查出某个用户的全部订单。第一版 SQL 写得很直白:SELECT * FROM orders WHERE user_id = ?。订单表刚上线那会儿只有几万行,这个查询几十毫秒就返回飞快。可半年之后订单表涨到了几千万行,这个查询慢得吓人——一次要五六秒,运营点一下要对着转圈干等,接口频繁超时。我第一反应几乎是条件反射:查询慢加…- 0
- 0
-
MySQL 索引失效完全指南:从一次 8 秒慢查询看懂索引为什么没走
2022 年我维护一个订单查询系统,orders 表几百万行。某天 DBA 告警:一个按日期查订单的接口慢到 8 秒,数据库 CPU 被一条 SQL 打满。我清楚记得 created_at 列上建了索引,可 EXPLAIN 一看 type=ALL、key=NULL——索引根本没走,几百万行从头扫到尾。罪魁是 WHERE DATE(created_at)= 这种写法:对一个建了索引的列套了 DATE…- 2
- 0
-
加了索引还是全表扫描:一次 MySQL 索引失效排查的复盘
查询接口上线后慢查询频繁告警,WHERE 列明明建了索引,EXPLAIN 却是 type=ALL 全表扫描。根子是踩中了一堆隐蔽的索引失效场景。几天系统梳理:索引列套函数、隐式类型转换、联合索引最左前缀、LIKE 前导通配符、优化器算账放弃索引,以及 EXPLAIN 排查方法论。- 0
- 0
SQL优化
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×