搞数据库的谁没被几个慢查询折磨过。尤其是MySQL明明给字段建了索引结果一条SQL下去全表扫描几百万行数据硬怼生产环境差点被打挂。我调优过很多次线上慢SQL总结下来绝大多数问题都不是索引没建而是建了索引却没用上也就是典型的Mysql索引失效。这篇文章我就把工作中真正遇到过的、排查过的15个索引失效场景拆开揉碎了讲每个场景都会说清楚触发原因、复现SQL和解决思路帮你以后写SQL时能一眼看出问题。这篇东西适合谁看刚入门想搞懂EXPLAIN的新手、写了好几年业务代码但没深究过索引原理的后端开发以及在运维线上库时被慢查询搞得焦头烂额的DBA都能从中捞到点东西。不夸张地讲把这15个场景吃透你日常遇到的慢查询至少能自己解决八成。1. 索引失效的内功心法先弄懂优化器是怎么干活的在开撕具体场景之前得先把底层逻辑讲透。很多文章上来就扔15个失效场景读者背下来了换个场景又不会了。知其所以然才能真正避坑。1.1 索引失效的本质是优化器的“选择”先说一个很多人没意识到的事实索引失效并不是索引坏了而是MySQL的查询优化器在特定条件下认为“走索引还不如全表扫描快”于是主动放弃了索引。你别觉得优化器蠢它其实是在综合判断一个SQL的执行代价。代价估算考虑的因素包括要扫描多少行、要回表多少次、排序要不要额外开销、内存够不够等等。举个例子一张表一共就100行数据你给某个字段建了索引查的时候优化器一算走辅助索引要查二级索引树找到主键ID再回表聚簇索引取整行数据来回折腾可能要访问200个数据页而直接全表扫描顺序读100个数据页就搞定了。那它当然选择全表扫描这叫“优化器认为全表扫描更优”是合理的失效。最坑的是另一种情况数据量很大明明走索引更快但因为统计信息不准确优化器误判了行数也选择了全表扫描这就是后面要说的统计信息过期导致的失效。还有个基础概念必须提——回表。MySQL的InnoDB引擎里主键索引聚簇索引的叶子节点存的是整行数据二级索引普通索引的叶子节点存的是主键值。你查询的字段不在二级索引里就得拿着主键值再去聚簇索引里找一次完整行这个过程就叫回表。回表次数多了性能损耗巨大所以优化器特别在意回表成本。1.2 排查索引失效EXPLAIN是唯一真相所有所谓的“索引失效”都要靠EXPLAIN来实锤。我排查问题的惯例是拿到一条慢SQL第一件事就是跑EXPLAIN看执行计划。重点看几个字段type访问类型。从好到差依次是 system const eq_ref ref range index ALL。看到ALL基本就是全表扫描索引大概率失效了看到index是扫描了整棵索引树也好不到哪去。key实际用到的索引。如果为NULL说明没走任何索引。rows预估扫描行数。和实际行数对比差距巨大就要怀疑统计信息。Extra这个字段信息量最大。出现Using index说明用了覆盖索引Using index condition说明用了索引下推Using where说明存储引擎层返回记录后又被server层过滤了Using filesort说明排序没走索引需要额外文件排序Using temporary说明用了临时表。我经常把EXPLAIN比作医院的CT报告SQL写得好不好一眼就能扫出来。有很多开发同学找我调优上来就说“我加了索引怎么还慢”结果一跑EXPLAINtypeALLkeyNULL那问题根本不在索引有没有建而是SQL写法导致索引压根没被用上。还要注意EXPLAIN的结果只是个预估不是真实执行情况。Oracle里有个DBMS_XPLAN能看实际执行计划MySQL里要看真实性能更靠谱的是打开profiling或者直接看慢查询日志里的实际执行时间和Rows_examined。我之前就遇到过EXPLAIN显示走了索引结果Rows_examined比表总行数还多的情况那就是谓词越界导致的幽灵扫描后面细说。1.3 15个失效场景的分类认知这15个场景我会按照底层原因分成四大类来讲优化器层面函数操作、隐式类型转换、隐式字符集转换、排序无法利用索引。索引结构层面联合索引最左前缀失效、范围查询右侧列失效、前导模糊匹配失效。SQL写法层面OR连接、NOT IN、IS NULL、SELECT *、索引列参与运算。统计与版本层面统计信息过期、优化器误判、MySQL版本差异。这四个层面你会发现在实战中经常叠加出现。比如一个SQL里既有函数又有OR那排查时要逐个条件拆开看到底是哪一层导致索引被废了。掌握好分类以后遇到陌生场景也能自己归因。2. 优化器层面的失效函数、类型转换与字符集这类失效最隐蔽因为SQL看起来完全正常表结构也没问题但就是不走索引。排查这类问题有个规律凡是索引列被“加工”过的索引基本就废了。2.1 场景一索引列上使用函数或计算这是我们最常踩的坑。假设有一张用户表几百万行给 create_time 建了索引你想查2025年3月创建的用户SELECT * FROM users WHERE DATE(create_time) 2025-03-01;这条SQL看起来很美好但优化器面对 DATE(create_time) 的时候无法直接比较索引中存储的原始值必须先把每一行的 create_time 取出来调用DATE()函数转换后再匹配。索引树是按原始值排序的你给它套了一层函数排序规则直接失效优化器只能放弃索引全表扫描。正确写法是直接拿原始值和范围比较SELECT * FROM users WHERE create_time 2025-03-01 00:00:00 AND create_time 2025-03-02 00:00:00;这样优化器就能利用索引进行范围扫描效率天差地别。类似的高频函数还有 LEFT(phone, 3)、YEAR(create_time)、SUBSTRING(name, 1, 2) 等等凡是出现在WHERE子句里对索引列做加工的情况都要警惕。有一种特殊情况得说MySQL 8.0.13以上版本开始支持函数索引比如你可以直接建一个索引指向LEFT(phone, 3)。但函数索引本身限制了查询条件的写法必须和定义完全一致才能命中实际开发中我更推荐直接改写SQL。2.2 场景二隐式类型转换这个场景的隐蔽程度极高因为你感觉自己在写正常SQL但MySQL已经在背后默默把索引列的类型做了转换。经典的翻车现场表里 phone 字段是 varchar 类型也建了唯一索引然后你写了这么一条SELECT * FROM users WHERE phone 13812345678;这条SQL在MySQL里执行是能出结果的也正因为能出结果很多人根本察觉不到问题。但事实上因为你传了一个整数和字符串类型的索引列比较MySQL会隐式地把 phone 转换成数字再比较。这个转换动作发生在每一行上索引树又失效了EXPLAIN结果就是 typeALL、rows几百万。原理很简单当索引列是字符串、传入值是数字时MySQL会放弃索引因为字符串转数字是非确定性操作反过来当索引列是数字、传入值是字符串时如果能明确转成数字且不改变排序优化器通常还能用上索引。所以最稳妥的做法是传参时严格按照字段类型来。-- 正确姿势加引号 SELECT * FROM users WHERE phone 13812345678;我还见过一个经典的生产事故两个表关联查询一个字段是int另一个是varcharJOIN时发生了隐式转换驱动表的索引直接失效造成千万级笛卡尔积式的全表扫描。排查这类问题的小技巧看EXPLAIN时如果发现 typeALL 但 SQL 里没有明显函数优先检查字段类型是否匹配。2.3 场景三隐式字符集转换这个坑是隐式类型转换的姊妹篇但更隐蔽因为类型一样都是字符串只是字符集不一样。MySQL做表连接时如果连接字段的字符集不一致它会先把其中一个字段的字符集转换成另一个这个转换也会让索引失效。真实案例订单表 order_no 用 utf8mb4用户表 user_no 用 utf8 或 latin1JOIN的时候一看字段都是varchar类型匹配但EXPLAIN出来驱动表索引失效全表扫描。排查出来后我们改了表字符集统一成 utf8mb4性能马上恢复。-- 用CONVERT显式让字段转成同一字符集虽然能走索引但会导致驱动表全扫 -- 最靠谱做法直接ALTER TABLE统一字符集 SELECT * FROM orders o JOIN users u ON o.user_no CONVERT(u.user_no USING utf8mb4);这里要强调不建议用CONVERT来“解决”问题因为牵涉到将一侧的字符串转换后与另一侧比较本质上还是有一侧的索引会失效。最好的方案是保持同一张库的字符集全局统一。建库时统一用utf8mb4后面会少很多这种莫名其妙的坑。2.4 场景四前导模糊查询LIKE %关键字LIKE查询的经典陷阱不用多说都知道LIKE %abc和LIKE %abc%走不了索引因为字符串匹配必须从第一个字符开始定位最左前缀为%时B树的排序特性根本无法利用。但很多人不知道的是LIKE abc%是可以走索引的而且工作得很不错。-- 走不了索引 SELECT * FROM articles WHERE title LIKE %MySQL优化%; -- 走索引最左前缀匹配 SELECT * FROM articles WHERE title LIKE MySQL优化%;那如果业务真的需要查“包含某个关键词”怎么办三个方案可以参考方案一用全文索引FULLTEXTMySQL自带全文检索但中文分词支持一般。方案二引入Elasticsearch等搜索引擎业务量大时的正解。方案三覆盖索引兜底。如果只要返回某几个字段而这些字段恰好都在索引里优化器会为了不回表而选择扫描整个二级索引typeindex虽然也扫了整棵索引树但索引树通常比表小很多速度还是比全表扫描快。我在实际项目中发现很多“搜索”需求本质是精确匹配或前缀匹配产品经理嘴上说的模糊搜索你跟他确认一下其实能改成前缀匹配甚至等值匹配。这个需求对齐的过程就能帮你省掉一个ES集群的运维成本。3. 索引结构层面的失效联合索引与范围查询联合索引是面试高频题也是日常开发最容易写错的点。先记住底层逻辑联合索引的B树先按第一个字段排序第一个字段相同时按第二个字段排序以此类推。这决定了它遵循“最左前缀原则”——从联合索引的最左边字段开始连续的条件才能命中索引。3.1 场景五违反最左前缀原则假设有一个联合索引 (a, b, c)查询条件是WHERE b 1 AND c 2那么很不幸这个索引完全没用上。为什么因为B树先按a排了序跳过a直接用b去查找索引树的结构就派不上用场了。但有几个容易误解的点得掰开讲清楚WHERE a 1 AND c 2能走索引吗能但只用到了a字段的索引c用不上。因为a确定后数据在b字段上是有序的但c字段只在a和b相同时才有序跳过b直接查c没法二分定位。WHERE a 1 AND b 5 AND c 3呢a走了索引等值匹配b走范围扫描c的索引条件失效。原因和范围查询右侧列失效是同一个原理。如果你不知道字段里到底哪些值会传过来设计联合索引时把等值匹配的字段放前面范围查询的字段放后面这是一个非常实用的经验法则。3.2 场景六范围查询右侧索引列失效联合索引的场景通病单拎出来说。还是索引 (a, b, c)SQL是SELECT * FROM table WHERE a 1 AND b 2;优化器可以用a的范围条件在索引树上找到一批记录但是注意这批记录里b字段并不是有序的。因为B树上只有当a字段值相同时b字段才有序a是一个范围值意味着b的有序性被破坏了所以WHERE b 2这个条件没办法在索引上精确定位只能把a1命中的每条记录取出来逐一比对b2。这就是所谓的范围查询右侧列失效。解决办法是调整索引设计把范围查询字段放在联合索引最后把等值查询字段放在前面比如改成 (b, a) 联合索引这样b2能精确定位a1再在结果集内做范围扫描。实际调优时我经常把这个规则和业务查询频率结合起来等值查询最频繁的字段永远放第一位范围条件次之排序字段放最后。3.3 场景七ORDER BY与WHERE字段顺序不一致导致排序索引失效很多人以为ORDER BY只要走索引就行忽略了WHERE和ORDER BY的组合规则。一张表有联合索引 (a, b)你执行SELECT * FROM table WHERE a 1 ORDER BY c;可能走索引也可能不走取决于优化器怎么选。更典型的翻车是-- 联合索引(a, b)排序顺序不匹配 SELECT * FROM table WHERE a 1 ORDER BY b DESC;如果索引里b是升序你要求降序MySQL 8.0之前只能额外做文件排序filesortEXPLAIN里会出现Using filesort性能损耗极大。MySQL 8.0开始支持降序索引可以建INDEX idx_a_b (a ASC, b DESC)来匹配。但这不是最关键的关键是要理解WHERE的等值条件确定了索引前缀后面的ORDER BY字段必须和索引剩余字段完全按顺序对齐否则就会filesort。我在一个报表系统里就见过查询最近一周数据并按金额排序金额字段是二级索引但WHERE用时间范围ORDER BY用金额结果优化器无论怎么选都无法同时满足两个条件只能先取出一堆数据再排序。后来改成联合索引(时间, 金额)排序直接走索引查询时间从3秒降到50毫秒。这个改造的收益就是理解WHERE与ORDER BY联合匹配规则的直观体现。3.4 场景八SELECT *造成的覆盖索引失效这个场景严格来说叫效率降低不算完全失效但很多人把它当成失效了。当索引包含了查询需要的所有字段时就是覆盖索引执行计划Extra里会显示Using index此时查询无需回表性能极好。但如果你写了SELECT *而索引只覆盖了部分字段那么所有命中的行都得回表取完整数据性能急剧下降。-- 假设有联合索引(user_no, status)下面这条只能回表 SELECT * FROM orders WHERE user_no u1001 AND status 1; -- 这个只查两个字段直接用覆盖索引Extra是Using index SELECT user_no, status FROM orders WHERE user_no u1001 AND status 1;实际业务中不可能所有查询都不SELECT *但针对高频低数据量的查询用覆盖索引加按需字段返回是一个成本极低又立竿见影的优化手段。我见过一个用户中心的查询日均调用量几百万所有字段都要返回怎么也优化不好后来只把高频接口的查询语句精简到索引覆盖的字段响应时间直接减半。4. SQL写法层面的失效OR、NOT IN与空值判断这一层最常见因为都是业务开发顺手写的SQL看起来没毛病实际全是坑。核心逻辑一句话概括优化器能利用索引前提是它能从索引树上有序地找到目标一旦条件要求它做“排除法”或“求并集”索引的便利性就没了。4.1 场景九OR连接导致索引失效先看SQLSELECT * FROM users WHERE name 张三 OR age 25;假设name和age都单独建了索引MySQL优化器面对OR条件按道理可以分别走两个索引取交集合并求并集早期版本确实不行新版MySQL能做Index Merge优化但有一个前提OR两侧必须都是索引列且优化器判断合并成本比全表扫描更低。实际经常遇到的情况是name有索引age有索引但还有个条件是address xxx而address没有索引那么OR里面有一个没索引整条SQL全表扫描。为什么因为OR求的是并集只要有一个分支需要全表扫描另一个分支即使走了索引也没法跳过全表扫描那一支。替代方案把OR语句拆成两个SELECT用UNION ALL合并SELECT * FROM users WHERE name 张三 UNION ALL SELECT * FROM users WHERE age 25 AND name 张三;这么拆两个分支各自都可以走索引再用UNION合并结果很多场景下能明显提速。但要注意UNION ALL比UNION快因为UNION会去重如果有重复数据需要只在结果中出现一次才考虑用UNION。更重要的一点OR和IN的底层处理逻辑截然不同。WHERE name IN (张三, 李四, 王五)在MySQL优化器里通常会被改写成多个等值条件的组合是可以有效利用索引的。所以能用IN表达的逻辑别用OR串。4.2 场景十NOT IN和NOT EXISTS的索引陷阱NOT IN是另一个高频杀手。假设状态字段有索引你想查出所有“非删除”状态的记录SELECT * FROM orders WHERE status NOT IN (3, 4);优化器面对NOT IN很难直接利用B树有序性做快速定位因为“不等于”意味着你必须扫描所有可能的值逐一排除。大部分情况下会退化为全表扫描。NOT EXISTS也类似它不是简单的索引失效但经常因为子查询的存在主查询被迫全表扫描。这里有两个思路方案一改写为LEFT JOIN加上IS NULL判断。这个经典改写方式能把“排除”逻辑转换成“连接后找不匹配”往往可以走索引。方案二如果业务上能保证状态列非负值很少比如只有 3 和 4 是异常可以反向记为WHERE status IN (0, 1, 2)用正向来查索引有效利用语义一样但写法翻转了。我最开始调优时老是绕不出来后来想通了一件事B树擅长的是“找得到”不擅长“找不到”。逻辑上要排除东西就把它翻成“在某个范围内找得到”性能会好非常多。4.3 场景十一IS NULL与IS NOT NULL的索引失效这个场景在网上争议很大因为不同版本MySQL表现不一样。以InnoDB为例单列索引时IS NULL通常是能走索引的因为NULL值在索引中也有位置但是IS NOT NULL很多时候不走索引尤其是当表中NULL值占比很小时优化器认为全表扫描找非NULL更划算。更坑的是联合索引下使用IS NULLWHERE a IS NULL AND b 1可能a走了索引b的条件因为最左前缀加空值排序问题无法利用。所以生产环境遇到IS NULL不走索引我的建议通常不是去改SQL而是给字段设置默认值让业务SQL用等值判断而不是空值判断。比如状态字段默认填0查询条件写成WHERE status 0逻辑等价还走了索引。4.4 场景十二索引列参与运算这个和函数操作是亲戚但更容易被忽略。你给age字段建了索引查询SELECT * FROM users WHERE age 1 26;优化器不会自作主张帮你化简成age 25它看到age被4则运算包裹直接放弃索引。同样的问题还出现在WHERE id * 2 100这类写法上。解决很简单把运算挪到等号右侧让索引列保持“干净”。SELECT * FROM users WHERE age 26 - 1;这里要特别提醒有些开发同学把这种运算挪到右侧后发现优化器依然没走索引就怀疑结论错了。其实是因为那句SQL虽然改对了但索引列可能因为类型转换或字符集问题仍然失效。所以排查时要综合看别因为一个点就下结论。4.5 场景十三单列索引的多条件组合失效这个场景经常被忽略因为它和联合索引最左前缀不完全一样。假设一张业务表上有username索引、age索引、status索引三个独立的单列索引你查SELECT * FROM users WHERE username x AND age 20 AND status 1;MySQL 5.0之后支持Index Merge索引合并理论上可以合并三个索引的扫描结果。但生产上你会发现优化器经常选择其中区分度最高的一个索引其他条件在回表后用Using where过滤。原因很简单合并三个索引要访问三棵B树再把结果做交集成本不一定比单索引加过滤低。这类场景的最佳实践是建立联合索引而不是依赖多个单列索引。联合索引 (username, age, status) 一次索引扫描就定位所有条件IO次数少得多。我在规范里通常建议单列索引用于高频独立查询场景多个等值条件频繁同时出现时必须建联合索引。5. 统计信息与版本层面的失效优化器的黑盒这一层属于高阶调优内容很多人性能调优到瓶颈后才发现问题根本不在SQL写法而在于优化器手里的“情报”不准。5.1 场景十四统计信息过期导致走错索引MySQL优化器决定走哪个索引依赖的是统计信息包括表行数、索引基数区分度、数据分布等。InnoDB的统计信息是采样估算的通过random dive等方式当表数据发生大量增删改后如果统计信息没有及时更新优化器可能拿着一张“过时的地图”做决策。典型翻车症状明明字段区分度很高也有索引但EXPLAIN显示优化器选了另一个区分度低的索引或者干脆全表扫描rows估值远低于实际行数。这时候手动执行ANALYZE TABLE users;强制刷新统计信息大概率能恢复。如果刷新后仍然选错可以考虑用FORCE INDEX强制指定索引SELECT * FROM users FORCE INDEX (idx_username) WHERE username admin;但FORCE INDEX是下策属于“打补丁”因为后续数据分布变化后这个强制选择可能又不是最优的了。根本解法是优化SQL写法让优化器可选的方案都足够好它自然就会选对。5.2 场景十五优化器误判与MySQL版本差异这个场景最“妖”因为有些SQL在测试环境跑得好好的上到生产就变慢或者5.7上正常的SQL迁移到8.0后执行计划变了。比如MySQL 5.6之前对某些子查询优化得很差IN子查询会物化成临时表且临时表无索引导致大表驱动性能完全崩掉。5.6引入了半连接semi-join优化5.7进一步改进8.0的hash join也让这类场景有了转机。8.0.18之后引入了hash join某些原先走索引的两表连接优化器通过代价模型判断hash join用内存换时间更快于是执行计划变了。这时候别慌先确认hash join是否真的更快有时优化器算错了。我的习惯是线上数据库大版本升级后一定要回归核心SQL的执行计划。曾有一次MySQL 5.7升8.0后某条报表SQL从300毫秒变成3秒排查发现是where条件里一个隐式类型转换在8.0下优化方式变了导致索引失效。最后改写SQL才稳定。版本升级不是小事执行计划一定要盯。5.3 关于索引失效的“薛定谔”现象可能有人会问同样的SQL为什么有时候走索引有时候不走这就是优化器的黑盒特性。同一个SQL老练上去由于绑定变量、统计信息更新、系统负载变化等原因执行计划可能漂移。这就更要养成习惯上线前先EXPLAIN上线后观察慢查询日志和performance_schema别只在测试环境看一眼就完事。还有一个容易被忽略的点小表不走索引是正常现象。比如一张表只有几十行你给它加索引查询时优化器八成选择全表扫描。这在功能上没有错但如果你拿着“为什么我加索引了EXPLAIN还在扫描全表”来问你得先看行数。这是我做培训时反复强调的先看表有多大再谈索引失效。6. 实战总览15个场景速查表与经验心得聊了这么多理论最终还是得落到可以直接抄作业的表格上。下表把上述场景汇总成速查目录方便你排查慢SQL时对照。序号失效场景典型特征解决思路排查关键字1索引列使用函数WHERE DATE(create_time)...改写为范围条件DATE()、LEFT()2隐式类型转换varchar字段传int传参严格匹配字段类型字符串类型列无引号3隐式字符集转换多表JOIN字段字符集不同统一库表字符集utf8与utf8mb4混用4前导模糊查询LIKE %xx改前缀匹配或全文索引LIKE %...%5违反最左前缀跳过了联合索引第一个字段调整查询条件或索引顺序联合索引查询6范围查询右侧列WHERE a1 AND b2范围字段放索引最后联合索引范围7排序字段顺序不匹配ORDER BY字段与索引顺序不一致调整索引顺序或用降序索引Using filesort8SELECT * 回表索引覆盖字段之外的列被查询按需字段覆盖索引Using where回表9OR连接非索引列OR两边条件索引情况不一致拆UNION ALLOR连接10NOT IN/NOT EXISTS排除逻辑翻转成正向IN或LEFT JOINNOT IN11IS NULL/IS NOT NULL空值判断默认值替代空值IS NULL12索引列参与运算WHERE id110运算移到右侧索引列四则运算13多单列索引组合等值条件分散在不同单列索引建联合索引Index Merge14统计信息过期行数估值严重失真ANALYZE TABLErows估值异常15优化器误判/版本差异执行计划漂移、版本升级后变慢改写SQL或FORCE INDEX版本升级回归6.1 排查索引失效的SOP说了这么多总的排查流程得固化下来变成肌肉记忆。我在团队内部推的标准流程是这样的第一步拿到慢SQL先EXPLAIN看type、key、rows、Extra四件套。第二步如果type是ALL或index按本文速查表逐个排除。先看SQL写法层面函数、运算、隐式转换、OR、LIKE再看索引结构层面联合索引顺序、排序最后确认统计信息。第三步定位到具体原因后别急着改索引。先想业务上能不能改写SQL达成同样效果因为改SQL成本最低、风险最小。改不了才动索引设计。第四步改完必须验证对比执行计划和实际耗时。我个人有一个原则优化必须是可度量的改之前记录基准性能改之后对比提升不然全是玄学。6.2 从索引失效到索引设计的思维升级最后说点掏心窝的话。我见过太多团队SQL慢了就加索引加了索引还慢就再加一个索引越建越多写操作的性能越来越差最后整个库被拖垮。索引失效的问题本质上不只是“SQL写法”问题更是“索引设计是否贴合业务”的问题。如果你发现某个场景频繁触发索引失效比如经常有人在某个联合索引上只用第二个字段查询那说明这个索引设计根本不符合业务查询习惯应该直接调整索引字段顺序而不是逼着开发同学每次写SQL都小心翼翼。索引是为查询服务的查询是业务的影子设计索引之前先把业务查询模式梳理清楚索引失效的概率会急剧下降。还有一点经验分享我维护的系统中索引并不是越多越好。每多一个索引INSERT/UPDATE都要同步维护一棵B树写放大效应明显。所以我给团队定的规范是单表索引数量控制在5个左右联合索引优先于多个单列索引低频查询不要单独建索引让慢查询日志自己说话。这个思路执行下来线上库的写入性能和存储成本都健康了很多。遇到快反系统或全文搜索需求时也别死磕MySQL索引Elasticsearch、ClickHouse这些专用引擎在某些场景下能让你的架构瞬间清爽。但常规的业务CRUD吃透这15个索引失效场景你已经能在数据库调优这条路上走得很远了。
