-
我明明给表建了联合索引,有些查询却还是慢得像全表扫描,EXPLAIN 一看根本没走索引,因为我的查询条件不符合最左前缀:一次数据库联合索引最左前缀的深度复盘
我有张订单表,经常按用户、状态、时间查,于是建了个联合索引 (user_id, status, created_at),以为这几个字段的查询都能走它、飞快。可线上有些查询慢得像全表扫描,EXPLAIN 一看傻眼:它们根本没走这个联合索引(type=ALL)。那些慢查询要么只按 status 查(没带最左的 user_id),要么 status+created_at(跳过了 user_id)。查清才…- 0
- 0
-
列表页前几页飞快、翻到几千页后接口直接超时,我用 LIMIT 一百万逗号二十去查那一页才发现数据库默默扫描并丢弃了前一百万行:一次深度分页 LIMIT offset 性能塌陷的深度复盘
我做了个数据列表页支持翻页,后端分页用最常见的 SELECT * FROM orders ORDER BY id LIMIT offset, size。前几页飞快,可用户翻到很靠后的页(第几千页)接口就慢到超时 500。抓出那条慢 SQL 一看 offset 已到百万级。EXPLAIN 才发现:LIMIT 1000000, 20 不是直接跳到第 1000000 行取 20 条,而是从头扫描并丢弃前…- 0
- 0
-
我给查询字段建好了索引,一条简单的查询却慢得离谱,EXPLAIN 一看竟然全表扫描根本没走索引,我对着在索引列上用函数和隐式类型转换让索引失效这个坑排查大半天的复盘
一个让我对数据库索引从迷信到敬畏的经典坑,崩溃在索引明明就在那、查询条件明明用了那个建了索引的字段,数据库却视而不见去全表扫描。慢查询告警:users 表几百万行,phone 字段 varchar 上早建好索引 idx_phone,按手机号查的接口平时飞快,那天突然几百毫秒甚至上秒。SQL 简单得不能再简单:SELECT * FROM users WHERE phone = 13800138000…- 4
- 0
-
我的查询明明在手机号字段上建了索引,却慢得像在全表扫描,EXPLAIN 一看果然没走索引,折腾半天发现罪魁祸首竟是一个隐式类型转换的深度复盘
一张几百万行的用户表,我早早在 phone 字段建了索引,可"按手机号查用户"的 SQL 慢得动辄上千毫秒,跟全表扫描没区别。我一度想重建索引、加配置,最后老老实实 EXPLAIN 一看:type=ALL、key=NULL,根本没走索引!细看才发现:phone 是 varchar,我却写成 WHERE phone = 13800138000 把它当数字传了。MySQL 比较字符…- 0
- 0
-
明明有索引却全表扫描:索引失效避坑复盘
那次事故把我对我明明建了索引啊这句话的信心彻底击碎了:一个按手机号查询用户的接口上线一年多一直稳稳的响应几毫秒,突然某天开始偶发性地慢到好几秒甚至超时。SQL 简单到不能再简单,就是 WHERE phone = ?,而 phone 字段上我清清楚楚建了索引,一个走索引的等值查询几百万行的表里也该毫秒级返回,怎么会慢到几秒?真正让我脊背发凉的是把这条慢 SQL 拿去 EXPLAIN 的那一刻——它居…- 0
- 0
-
测试秒回上线却超时:MySQL 索引为何悄悄失效
一条订单查询,开发时毫秒返回,测试环境秒回验收一路绿灯,上线没几周却动辄八九秒甚至超时——而代码和 SQL 一个字都没改。登上服务器一看,CPU、连接数都正常,唯独慢查询日志里它赫然在列;在前面加上 EXPLAIN 才心里咯噔一下:type 是 ALL、rows 几百万、key 那栏空空如也,明明建了索引却压根没走,老老实实把整张表从头扫到尾。真凶经典得让我有点不好意思:字段是 varchar 存…- 0
- 0
-
一条慢 SQL 打满数据库:那些让你索引白建的失效陷阱
一个普通的下午,接口突然集体超时,数据库 CPU 被打满到 100%,而 QPS 看起来一切正常。揪出凶手只用了一条 EXPLAIN——一条平时几毫秒的查询变成了十几秒的全表扫描,明明建了索引却纹丝不动。从那次事故出发,这篇文章把索引失效的六大陷阱、EXPLAIN 怎么读、联合索引最左前缀、覆盖索引、深分页优化到慢查询日志监控,一次讲透。- 0
- 0
-
MySQL 慢查询从定位到根治:索引失效、深分页、长事务的排查与优化清单
一套跑了四五年、订单表从几十万行涨到三千多万行的分析库,一条 WHERE DATE(created_at)=CURDATE() 的汇总查询因为在索引列上套了函数而退化成全表扫描,单条 SQL 从设计期的几毫秒涨到线上 18 秒,高并发下迅速占满连接池让整块经营看板瘫痪。这篇不写成「几个人熬了多少天打了多少仗」的流水账,而是整理成一份能直接照着查的慢查询治理清单:先用慢查询日志(long_query…- 0
- 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 索引调优完全指南:从一次"500GB CRM 库核心查询 30 秒大客户列表页崩溃"看懂为什么 CREATE INDEX 远远不够
2023 年我们接手一个 SaaS CRM 系统用 PostgreSQL 14 业务起来后客户数据库从 10GB 涨到 500GB 一些核心查询从 50ms 慢慢恶化到 30 秒大客户列表页要等半分钟才出来客户投诉一通接一通我们老板拍板说加索引我们也就加索引这一加发现完全不是 CREATE INDEX 一句话的事加完该慢的还慢不该慢的反而慢了业务直接更崩然后我们陆续踩了一堆坑第一种最让我傻眼我们看…- 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
-
数据库索引为什么用 B+ 树?从原理到实战的深度解析
"查询慢?加个索引。"几乎每个后端都听过这句话,也照做过。但索引为什么能让查询快、为什么数据库底层偏偏选了 B+ 树这个数据结构、为什么有时候加了索引还是慢、什么时候不该加索引 —— 这些问题能讲清楚的人就不多了。这篇从"没有索引会怎样"出发,一步步推到 B+ 树,再落到实战里索引为什么会失效、该怎么用对。看完之后,你对索引的理解会从"背规则&qu…- 5
- 0
索引
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×