搜狐技术产品

重生之MySQL 索引失效六大陷阱

书接上回,林渊盯着监控屏上跳动的QPS 18500,突然发现商品搜索接口的Handler_read_next计数器每秒暴涨百万次。"

这是全表扫描的死亡信号!"他抓起对讲机:"立刻降级推荐系统!"

技术总监老吴却按住他的手:"活动还有1分钟开始,现在降级等于自杀!"

机房突然陷入黑暗——过载的UPS触发了熔断保护。

陷阱一:类型转换

▎故障现场

SELECT * FROM products 
WHERE category_id = '3'-- 字段实际类型为INT
ANDstatus = 1-- 字段类型为ENUM('0','1')

揭示灾难路径:

Image

修复术:

-- 强制类型精确匹配
SELECT * FROM products 
WHERE category_id = CAST('3'AS SIGNED) 
ANDstatus = CAST(1ASCHAR)

陷阱二:函数操作

▎价格区间查询

SELECT * FROM products
WHEREFLOOR(price/100)*100 = 500-- 破坏索引有序性

B+树结构破坏验证:

Image

陷阱三:最左前缀

复合索引idx_cat_status(category,status)失效现场:

SELECT * FROM products WHEREstatus=1

B+树物理扫描路径:

Image
# 执行计划对比
全索引扫描: 230ms  
全表扫描:  380ms  # 因需要回表反而更慢

陷阱四:隐式字符集转换

跨表查询的隐藏炸弹:

SELECT * FROM orders o 
JOINusers u ON o.user_id = u.id 
WHERE u.name='林渊'

字符集差异诊断:

Image

解法:

ALTERTABLEusersCONVERTTOCHARACTERSET utf8;

陷阱五:最左匹配

复合索引idx_time_status(create_time,status)失效案例:

SELECT * FROMlogs
WHEREstatus = 'SUCCESS'

陷阱六:索引选择器

优化器的致命误判:

SELECT * FROM products 
WHERE category_id = 3
AND is_hot = 1
ORDERBY price DESC

索引选择矩阵:

Image

强制干预方案:

SELECT * FROM products 
FORCEINDEX(idx_category) 
WHERE category_id = 3AND is_hot = 1
ORDERBY price DESC

索引检验工具包

# 索引有效性核验套件
mysql> SHOW INDEX FROM products WHERE Seq_in_index=1;
# 字符集冲突检测
mysql> SELECT TABLE_NAME,COLUMN_NAME,COLLATION_NAME 
       FROM information_schema.COLUMNS 
       WHERE COLLATION_NAME NOT LIKE 'utf8%';
# 隐式转换检测
mysql> EXPLAIN EXTENDED SELECT ...;
mysql> SHOW WARNINGS;  # 查看转换痕迹

总结

林渊在2003年的技术局限下,留下六大防御法则:

  1. 类型精确律:WHERE条件与字段类型绝对匹配
  2. 函数绝缘体:禁止在索引列包裹函数
  3. 左前缀铁律:复合索引首字段必须参与查询
  4. 字符集统一场:全库字符集强制校验
  5. 范围右侧禁区:范围查询后字段不进索引
  6. 优化器驯化术:FORCE INDEX与覆盖索引联用

往期推荐

MySQL:MyISAM锁表致千万损失!穿越工程师如何逆天改命

一次非常诡异的 JVM OOM 事故排查

Kafka 4.0 发布:KRaft 替代 Zookeeper、新一代重平衡协议、点对点消息模型、移除旧协议 API

38 张图详解 Redis:核心架构、发布订阅机制、9大数据类型底层原理、RDB和AOF 持久化、高可用架构、性能问题排查和调优

高并发系统必看!G1如何让亿级JVM吞吐量提升300%?

性能提升300%!JVM分配优化三板斧,JVM 的内存区域划分、对象内存布局、百万 QPS 优化实践

从 12s 到 200ms,MySQL 两千万订单数据 6 种深度分页优化全解析