-
商品按价格排序,9 块钱排在了 80 块后面:我在 JavaScript 里被 Array.sort() 默认按字符串排序坑惨的那次线上事故复盘
商品列表"按价格从低到高"排序,上线后却乱成一团:9 元排在 80 元后面,1000 元跑到 200 元前面。控制台一跑 [9,80,100,1000,200].sort() 得到 [100,1000,200,80,9]——真凶是 Array.sort() 不传比较函数时,默认把元素转成字符串、按字典序排,"100"- 0
- 0
-
一条 WHERE phone = 13800138000 漏了引号的查询,让 2000 万行的表全表扫描拖垮数据库:我在 MySQL 里栽进隐式类型转换让索引失效的深夜告警复盘
凌晨一点告警炸响:数据库 CPU 打满、接口大面积超时。慢查询日志里一条 SELECT ... WHERE phone = 13800138000 执行要 8 秒——phone 明明建了索引,EXPLAIN 却显示全表扫描 2000 万行。真凶是我把手机号写成了数字而非字符串:varchar 字段遇上数字常量,MySQL 会把每一行字段都做隐式类型转换,等于对索引字段做函数运算,索引彻底失效。这篇…- 0
- 0
-
明明有索引却全表扫描:索引失效避坑复盘
那次事故把我对我明明建了索引啊这句话的信心彻底击碎了:一个按手机号查询用户的接口上线一年多一直稳稳的响应几毫秒,突然某天开始偶发性地慢到好几秒甚至超时。SQL 简单到不能再简单,就是 WHERE phone = ?,而 phone 字段上我清清楚楚建了索引,一个走索引的等值查询几百万行的表里也该毫秒级返回,怎么会慢到几秒?真正让我脊背发凉的是把这条慢 SQL 拿去 EXPLAIN 的那一刻——它居…- 0
- 0
隐式类型转换
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×