-
我明明给表建了联合索引,有些查询却还是慢得像全表扫描,EXPLAIN 一看根本没走索引,因为我的查询条件不符合最左前缀:一次数据库联合索引最左前缀的深度复盘
我有张订单表,经常按用户、状态、时间查,于是建了个联合索引 (user_id, status, created_at),以为这几个字段的查询都能走它、飞快。可线上有些查询慢得像全表扫描,EXPLAIN 一看傻眼:它们根本没走这个联合索引(type=ALL)。那些慢查询要么只按 status 查(没带最左的 user_id),要么 status+created_at(跳过了 user_id)。查清才…- 0
- 0
-
一条 WHERE phone = 13800138000 漏了引号的查询,让 2000 万行的表全表扫描拖垮数据库:我在 MySQL 里栽进隐式类型转换让索引失效的深夜告警复盘
凌晨一点告警炸响:数据库 CPU 打满、接口大面积超时。慢查询日志里一条 SELECT ... WHERE phone = 13800138000 执行要 8 秒——phone 明明建了索引,EXPLAIN 却显示全表扫描 2000 万行。真凶是我把手机号写成了数字而非字符串:varchar 字段遇上数字常量,MySQL 会把每一行字段都做隐式类型转换,等于对索引字段做函数运算,索引彻底失效。这篇…- 2
- 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 怎么读、联合索引最左前缀、覆盖索引、深分页优化到慢查询日志监控,一次讲透。- 3
- 0
-
MySQL 索引优化实战:看懂 EXPLAIN,慢查询从 3 秒到 30 毫秒
一张订单表数据涨到两千万行后,一个按用户查最近订单的普通查询突然慢到三秒多,我第一反应是加索引,结果还是慢一秒多。那天我用 EXPLAIN 把它摊开,顺着 B+ 树、聚簇索引与二级索引的回表、覆盖索引、联合索引的最左前缀一路啃下来,最后靠建对一个索引把查询压到三十毫秒。从读懂 EXPLAIN 的 type/key/rows/Extra,到回表与覆盖索引、最左前缀、索引失效的函数与隐式转换与 LIK…- 0
- 0
-
MySQL 慢查询日志完全指南:从一次"每条 SQL 都不慢数据库却很卡"看懂慢查询定位
2023 年我维护一个订单服务后面接的是 MySQL 上线几个月后服务开始偶尔卡顿接口响应时快时慢高峰期尤其明显我判断是某些 SQL 慢了得把它们揪出来第一版我做得很顺手登上数据库把慢查询日志打开 long_query_time 设成 10 秒心想超过 10 秒的 SQL 总该是有问题的过几天来翻翻日志慢 SQL 就都躺在里面了我心里很笃定慢查询日志嘛不就是个开关打开它设个阈值慢的 SQL 自己会…- 0
- 0
-
MySQL 索引失效完全指南:从一次 8 秒慢查询看懂索引为什么没走
2022 年我维护一个订单查询系统,orders 表几百万行。某天 DBA 告警:一个按日期查订单的接口慢到 8 秒,数据库 CPU 被一条 SQL 打满。我清楚记得 created_at 列上建了索引,可 EXPLAIN 一看 type=ALL、key=NULL——索引根本没走,几百万行从头扫到尾。罪魁是 WHERE DATE(created_at)= 这种写法:对一个建了索引的列套了 DATE…- 2
- 0
-
搜索接口越来越慢:一次 ElasticSearch 慢查询优化的复盘
商品搜索接口 P99 从几十毫秒涨到两三秒,高峰偶发超时。我先入为主想加机器,profile 之后发现问题全在查询写法和索引设计上。几天彻底治理:slowlog+profile 定位、from+size 深翻页换 search_after、过滤条件移入 filter context、聚合用 keyword 治理 fielddata、分片数收敛、mapping 优化。- 2
- 0
-
PostgreSQL 6 亿行大表慢查询复盘:索引 + 分区 + 参数调优实战
PG 15 核心库单表 6 亿行,促销期 CPU 95%+,慢查询每分钟 500 条,连接打满。三周治理:pg_stat_statements 找 Top SQL + 复合/部分/BRIN 索引 + random_page_cost 参数 + 按月分区表 + PgBouncer 连接池 + autovacuum 调优。CPU 40%,P99 80ms。- 3
- 0
-
PostgreSQL 2TB 慢查询治理:从 30s 到 800ms 全实录
PG 14 集群 2TB 数据集慢查询泛滥,报表 30s 超时。一周优化全实录:auto_explain + pg_stat_statements 找罪魁,复合索引 + 局部索引 + 分区 + 物化视图 + autovacuum 调参 + pg_repack 重建,P99 从 30s 降到 800ms。- 0
- 0
慢查询
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×