线上问题-我就加了个索引怎么就导致线上事故了 关注更多AI编程资讯请去AI Coding专区：https://juejin.cn/aicoding 前言不好啦? 天塌了? 系统崩了? 「快看啊，一个上线 5 年的业务，今天发个版突然就崩了」 「生产问题群爆炸了」 ?我的心里活动：“太好了??太好了??终于给我碰上了，这个问题可很少发生啊，又积累血琳琳的生产一个问题” ?不想看废话的直接看【解决过程和方案】 吧 排查过程ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line// 问题sql select*fromw_locationwherelocation_type ='SORTING_TEMPORARY'ANDstatus ='1' 问题就是这个 sql 在线上查不到数据从而导致这个业务异常抛出。 但是我直连线上数据库发现这个条件是有数据的 然后查看发版记录，本次版本迭代改的跟这个功能毫无关系，甚至都没有发这个服务。真是奇了个怪，但是线上这里突然还是个必现的问题 接下来开始研究这个线上 sqlounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineCREATETABLE`w_location`(`id`bigint(19)NOTNULLCOMMENT'主键id',`warehouse_id`bigint(19)DEFAULTNULLCOMMENT'仓库id',`warehouse_code`varchar(20)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'仓库code',`location_code`varchar(20)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'库位编码',`tunnel_id`bigint(19)DEFAULTNULLCOMMENT'巷道id',`entity_type`varchar(20)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'实体类型',`high_low_type`varchar(20)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'高低类型',`row_number`tinyint(4) unsignedDEFAULTNULLCOMMENT'排',`column_number`tinyint(4) unsignedDEFAULTNULLCOMMENT'列',`floor_number`tinyint(4) unsignedDEFAULTNULLCOMMENT'层',`grid`char(1)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'格',`emp_loc`bit(1)DEFAULTNULLCOMMENT'是否空库位 0：不是空库位，1：是空库位',`location_classify_id`bigint(19)DEFAULTNULLCOMMENT'库位分类id',`status`bit(1)DEFAULTNULLCOMMENT'状态（1：生效，0：失效）',`load_id`bigint(19)DEFAULTNULLCOMMENT'库位承载id',`area_id`bigint(19)DEFAULTNULLCOMMENT'工作区id',`zone_id`bigint(19)DEFAULTNULLCOMMENT'库区id',`location_type`varchar(50)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'库位类型',`picking_sequence`mediumint(7)DEFAULTNULLCOMMENT'拣货动线号',`is_deleted`bit(1)DEFAULTNULLCOMMENT'是否删除',`inventory_sequence`mediumint(7)DEFAULTNULLCOMMENT'盘点动线号',`create_time`datetimeDEFAULTNULLCOMMENT'创建时间',`create_user`varchar(50)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'创建人',`update_time`datetimeDEFAULTNULLCOMMENT'更新时间',`update_user`varchar(50)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'更新人',`tenant_code`varchar(32)COLLATEutf8mb4_binNOTNULLCOMMENT'租户编码',`actual_temp_id`bigint(19)DEFAULTNULLCOMMENT'实际温层 ID',`actual_temp_code`varchar(20)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'实际温层 CODE',`create_nick_name`varchar(50)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'创建用户姓名',`update_nick_name`varchar(50)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'更新用户姓名',`production_line_id`bigint(19)DEFAULTNULLCOMMENT'生产线ID',`production_line_name`varchar(100)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'生产线名称',`instance_code`varchar(32)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'实例编码',`empty_flag`varchar(1)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'Y=空库位,N=非空库位;供点检使用',`picking_sequence_rearrangement`bigint(19)DEFAULTNULLCOMMENT'重排的拣货动线号',`inventory_sequence_rearrangement`bigint(19)DEFAULTNULLCOMMENT'重排的盘点动线号',`location_purpose`varchar(64)COLLATEutf8mb4_binDEFAULTNULLCOMMENT'库位用途',`casual_pick_loc`bit(1)DEFAULTb'0'COMMENT'是否临时拣货位',PRIMARYKEY(`id`)USINGBTREE,KEY`idx_wh_location_type`(`warehouse_code`,`location_code`,`location_type`),KEY`index_location_type_status`(`location_type`,`status`))ENGINE=InnoDBDEFAULTCHARSET=utf8mb4COLLATE=utf8mb4_binROW_FORMAT=DYNAMICCOMMENT='库位'; select *fromw_location where location_type ='SORTING_TEMPORARY'ANDstatus ='1' 这个 status 字段是 int 类型 怎么就参数还搞个字符串 然后还有 KEYindex_location_type_status(location_type,status) 这个索引 这让我一下子就联想到之前学习 mysql 时的一个知识点， 索引 + 隐式数据转换会带来意想不到的问题 「快速解决线上问题」 紧急联系 DBA 把发版的新增的索引给干掉 索引 + 隐式数据转换?MySQL 中隐式转换详细查看官方文档相关的说明： dev.mysql.com/doc/refman/…[1] ? 复现线上问题下面这三张图： 就可以很清晰的说明问题了： 索引 + 隐式数据转换会带来意想不到的问题 索引 + 隐式数据转换 理论解析根据现象分析，根本原因是 MySQL 的 bit 类型字段在索引查询时的隐式类型转换规则导致的。以下是具体解释： 问题核心原因： bit 类型存储特性： status 字段 bit(1) 实际存储的是二进制值： TRUE 存储为 b'1'（二进制值） FALSE 存储为 b'0' 索引影响下的隐式转换： 有索引时：status='1' → 需要将 bit 转为字符串比较（b'1' → "1"） status=1 → 将 bit 转为整数比较（b'1' → 1） 无索引时：两者都会做全表扫描，MySQL 统一进行类型转换 这个 case 只有 bit(1) 的时候 才会出现 bug?下面这俩 sql 你可以执行下 bit(1) 虽然存储的是 0 1 但他在 mysql 中 不是 int 类型 ?下面的介绍更全面 来源网友 总结存在索引的时候：status = '1'：字符串'1'的 ASCII 码为 49，与 bit(1) 的 b'1'（二进制值 1）不匹配，导致索引无法命中。 mysql 隐式转换的坑还有很多，并且隐式转化有很多默认规则，这个我们控制不来。 我们能做到的就是尽量避免隐式转换 点击关注公众号，“技术干货” 及时达！ 阅读原文