-
一个 varchar 手机号字段被用数字去查,MySQL 偷偷做隐式类型转换让索引彻底失效:一次慢查询拖垮数据库的深度排查与类型对齐正解
phone 字段是 varchar 且建了索引,一条 WHERE phone = 13800138000(少了引号,数字)却全表扫描三百多万行、跑了 8 秒、把数据库 CPU 打满。根因是 MySQL 隐式类型转换:字符串和数字比较时,它把字符串列转成数字,等于对每行 phone 做 CAST 运算,索引随之失效。本文从 EXPLAIN 看出 type=ALL/key=NULL 讲起,剖析隐式转换…- 0
- 0
-
我给查询字段建好了索引,一条简单的查询却慢得离谱,EXPLAIN 一看竟然全表扫描根本没走索引,我对着在索引列上用函数和隐式类型转换让索引失效这个坑排查大半天的复盘
一个让我对数据库索引从迷信到敬畏的经典坑,崩溃在索引明明就在那、查询条件明明用了那个建了索引的字段,数据库却视而不见去全表扫描。慢查询告警:users 表几百万行,phone 字段 varchar 上早建好索引 idx_phone,按手机号查的接口平时飞快,那天突然几百毫秒甚至上秒。SQL 简单得不能再简单:SELECT * FROM users WHERE phone = 13800138000…- 4
- 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
-
数据库索引失效完全指南:从一次"明明建了索引查询却还是全表扫描"看懂索引为什么没被用上
2023 年我做一个订单管理后台有个最常用的功能是按各种条件查订单按用户查按时间查按状态查数据量一上来这些查询开始变慢怎么让它快起来这件事我没多想就有了方案加索引第一版我做得很顺手查哪个列慢我就给哪个列建一个索引涉及到的列基本都建上了本地拿测试库一测确实快了不少我心里很笃定加索引嘛不就是哪个列查得慢就给哪个列建索引可等数据量再涨查询条件再变复杂一串问题冒了出来第一种最先把我打懵我明明给下单时间列建…- 2
- 0
-
数据库索引完全指南:从一次"明明加了索引、查询还是慢得要命"看懂索引失效
2021 年我做一个订单管理后台。有一个运营天天用的功能:按用户 ID 查出某个用户的全部订单。第一版 SQL 写得很直白:SELECT * FROM orders WHERE user_id = ?。订单表刚上线那会儿只有几万行,这个查询几十毫秒就返回飞快。可半年之后订单表涨到了几千万行,这个查询慢得吓人——一次要五六秒,运营点一下要对着转圈干等,接口频繁超时。我第一反应几乎是条件反射:查询慢加…- 0
- 0
索引失效
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×