一、BTree为什么适合数据库索引MySQL InnoDB 默认使用 BTree 索引。它的特点是多路平衡、层高低、叶子节点有序并通过链表相连。相比二叉树BTree 一次磁盘页能放更多 key查找通常只需要少量随机 IO相比哈希索引它天然支持范围查询、排序和最左前缀匹配。索引能力BTree表现典型场景等值查询很好id、订单号范围查询很好时间区间排序可利用有序性ORDER BY模糊前缀可部分利用name LIKE ‘ab%’后缀模糊难利用LIKE ‘%ab’二、联合索引与最左前缀联合索引不是多个单列索引的简单叠加。(tenant_id, status, created_at)的顺序决定了查询能走到哪里。等值条件通常放前面范围字段放后面排序字段要结合查询模式设计。CREATEINDEXidx_order_queryONorders(tenant_id,status,created_at);EXPLAINSELECTid,amountFROMordersWHEREtenant_id1001ANDstatusPAIDANDcreated_at2026-07-01ORDERBYcreated_atDESCLIMIT20;如果查询没有tenant_id这个索引很难高效使用。很多慢查询来自“看起来有索引”但实际条件不符合最左前缀。设计索引前应先收集高频 SQL而不是按字段名机械建索引。三、用EXPLAIN识别问题EXPLAIN是慢查询分析的入口。重点看type、key、rows、Extra。type从好到差大致是const、ref、range、index、ALL。如果rows很大且Extra出现Using filesort、Using temporary就要检查过滤条件和排序是否能被同一个索引支持。EXPLAINFORMATTREESELECT*FROMordersWHEREDATE(created_at)2026-07-08;上面这种写法会对列使用函数可能导致索引失效。应改成范围条件WHEREcreated_at2026-07-08 00:00:00ANDcreated_at2026-07-09 00:00:00同理隐式类型转换、前置百分号模糊查询、低选择性字段单独建索引都可能让优化器放弃索引。四、慢查询治理要闭环打开慢查询日志后不要只盯单条 SQL 的耗时还要看频率和扫描行数。一个 200 毫秒但每分钟执行上万次的查询影响可能比偶发 3 秒查询更大。SETGLOBALslow_query_logON;SETGLOBALlong_query_time0.5;生产环境应通过平台化方式采集慢日志按指纹聚合再结合业务上下文处理。索引不是越多越好写入、更新和磁盘占用都会随索引增加而上升。一次可靠的优化应包含确认慢 SQL、分析执行计划、设计或调整索引、压测验证、上线观察并清理不再使用的冗余索引。还要关注数据分布变化。一个索引在数据量小时表现很好半年后可能因为热点租户、状态字段倾斜或历史数据堆积而退化。可以定期查看表统计信息、索引基数和慢查询趋势。对于归档类数据冷热分离或分区表有时比继续堆索引更有效。索引优化不是一次性动作而是随业务增长持续校准访问路径。上线新索引也要评估写入成本。大表加索引可能耗时较长应选择低峰期必要时使用在线变更工具并提前准备回退方案。 本文是《数据库性能实战》系列持续更新关注不迷路。 下一篇《MySQL事务隔离级别与MVCC机制解析》讲索引之外事务可见性与锁范围如何影响并发。 你在实际项目里遇到过索引存在却没被优化器选中的问题吗评论区聊聊。觉得有用点个赞收藏方便回头查阅 相关可运行源码/资料已整理成资源包可在我主页的资源里自取。
一、BTree为什么适合数据库索引MySQL InnoDB 默认使用 BTree 索引。它的特点是多路平衡、层高低、叶子节点有序并通过链表相连。相比二叉树BTree 一次磁盘页能放更多 key查找通常只需要少量随机 IO相比哈希索引它天然支持范围查询、排序和最左前缀匹配。索引能力BTree表现典型场景等值查询很好id、订单号范围查询很好时间区间排序可利用有序性ORDER BY模糊前缀可部分利用name LIKE ‘ab%’后缀模糊难利用LIKE ‘%ab’二、联合索引与最左前缀联合索引不是多个单列索引的简单叠加。(tenant_id, status, created_at)的顺序决定了查询能走到哪里。等值条件通常放前面范围字段放后面排序字段要结合查询模式设计。CREATEINDEXidx_order_queryONorders(tenant_id,status,created_at);EXPLAINSELECTid,amountFROMordersWHEREtenant_id1001ANDstatusPAIDANDcreated_at2026-07-01ORDERBYcreated_atDESCLIMIT20;如果查询没有tenant_id这个索引很难高效使用。很多慢查询来自“看起来有索引”但实际条件不符合最左前缀。设计索引前应先收集高频 SQL而不是按字段名机械建索引。三、用EXPLAIN识别问题EXPLAIN是慢查询分析的入口。重点看type、key、rows、Extra。type从好到差大致是const、ref、range、index、ALL。如果rows很大且Extra出现Using filesort、Using temporary就要检查过滤条件和排序是否能被同一个索引支持。EXPLAINFORMATTREESELECT*FROMordersWHEREDATE(created_at)2026-07-08;上面这种写法会对列使用函数可能导致索引失效。应改成范围条件WHEREcreated_at2026-07-08 00:00:00ANDcreated_at2026-07-09 00:00:00同理隐式类型转换、前置百分号模糊查询、低选择性字段单独建索引都可能让优化器放弃索引。四、慢查询治理要闭环打开慢查询日志后不要只盯单条 SQL 的耗时还要看频率和扫描行数。一个 200 毫秒但每分钟执行上万次的查询影响可能比偶发 3 秒查询更大。SETGLOBALslow_query_logON;SETGLOBALlong_query_time0.5;生产环境应通过平台化方式采集慢日志按指纹聚合再结合业务上下文处理。索引不是越多越好写入、更新和磁盘占用都会随索引增加而上升。一次可靠的优化应包含确认慢 SQL、分析执行计划、设计或调整索引、压测验证、上线观察并清理不再使用的冗余索引。还要关注数据分布变化。一个索引在数据量小时表现很好半年后可能因为热点租户、状态字段倾斜或历史数据堆积而退化。可以定期查看表统计信息、索引基数和慢查询趋势。对于归档类数据冷热分离或分区表有时比继续堆索引更有效。索引优化不是一次性动作而是随业务增长持续校准访问路径。上线新索引也要评估写入成本。大表加索引可能耗时较长应选择低峰期必要时使用在线变更工具并提前准备回退方案。 本文是《数据库性能实战》系列持续更新关注不迷路。 下一篇《MySQL事务隔离级别与MVCC机制解析》讲索引之外事务可见性与锁范围如何影响并发。 你在实际项目里遇到过索引存在却没被优化器选中的问题吗评论区聊聊。觉得有用点个赞收藏方便回头查阅 相关可运行源码/资料已整理成资源包可在我主页的资源里自取。
