-
一个 varchar 手机号字段被用数字去查,MySQL 偷偷做隐式类型转换让索引彻底失效:一次慢查询拖垮数据库的深度排查与类型对齐正解
phone 字段是 varchar 且建了索引,一条 WHERE phone = 13800138000(少了引号,数字)却全表扫描三百多万行、跑了 8 秒、把数据库 CPU 打满。根因是 MySQL 隐式类型转换:字符串和数字比较时,它把字符串列转成数字,等于对每行 phone 做 CAST 运算,索引随之失效。本文从 EXPLAIN 看出 type=ALL/key=NULL 讲起,剖析隐式转换…- 0
- 0
-
我的查询明明在手机号字段上建了索引,却慢得像在全表扫描,EXPLAIN 一看果然没走索引,折腾半天发现罪魁祸首竟是一个隐式类型转换的深度复盘
一张几百万行的用户表,我早早在 phone 字段建了索引,可"按手机号查用户"的 SQL 慢得动辄上千毫秒,跟全表扫描没区别。我一度想重建索引、加配置,最后老老实实 EXPLAIN 一看:type=ALL、key=NULL,根本没走索引!细看才发现:phone 是 varchar,我却写成 WHERE phone = 13800138000 把它当数字传了。MySQL 比较字符…- 0
- 0
-
MySQL 慢查询从定位到根治:索引失效、深分页、长事务的排查与优化清单
一套跑了四五年、订单表从几十万行涨到三千多万行的分析库,一条 WHERE DATE(created_at)=CURDATE() 的汇总查询因为在索引列上套了函数而退化成全表扫描,单条 SQL 从设计期的几毫秒涨到线上 18 秒,高并发下迅速占满连接池让整块经营看板瘫痪。这篇不写成「几个人熬了多少天打了多少仗」的流水账,而是整理成一份能直接照着查的慢查询治理清单:先用慢查询日志(long_query…- 0
- 0
-
数据库慢查询优化完全指南:从一次"数据量一大接口就卡死、加了索引却没用"看懂慢查询治理
2021 年我做一个电商后台有一个订单列表接口。第一版我做得很省事写一句 SQL 把订单查出来按时间倒序分页返回。开发期和测试环境我测了测真不错翻页飞快几十毫秒就返回。我心里很踏实查数据库嘛写条 SQL 查出来就行了真慢了给条件列加个索引不就快了。可等这个系统真正上线订单表的数据从几万行涨到几百万行一串问题冒了出来。第一种最先把我打懵数据量一大这个列表接口直接卡死一次查询要几十秒接口频频超时。第二…- 5
- 0
慢查询优化
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×