TiDB 索引优化实战：从慢查询到性能飞升
在分布式数据库 TiDB 的使用过程中，索引优化是提升查询性能的关键手段之一。不少开发者在面对慢查询时，往往陷入 “加索引却不生效”“索引过多拖慢写入” 的困境。本文将结合实战场景，带你从慢查询分析入手，掌握 TiDB 索引优化的核心思路与操作方法。
一、慢查询溯源：找到性能瓶颈的 “指南针”
当业务系统出现查询延迟时，第一步是定位慢查询语句。我们可以通过 TiDB 的慢查询日志（默认路径 tidb-slow.log）或监控平台（如 Prometheus + Grafana）筛选出执行时间过长的 SQL。
以某电商订单查询场景为例，一条查询 “近 7 天未付款订单” 的 SQL 执行耗时 5 秒：
sql
SELECT order_id, user_id, amount, create_time
FROM orders
WHERE status = ‘unpaid’ AND create_time > ‘2025-10-01 00:00:00’;
通过 EXPLAIN 分析执行计划，发现该语句走了全表扫描（type: table_scan），未命中任何索引 —— 这就是性能瓶颈的关键。
二、索引设计的 “黄金法则”：适配业务与存储引擎
TiDB 基于 Raft 协议实现分布式存储，其索引原理与传统数据库既有共性，也有特性。设计索引时需遵循以下原则：
- 优先覆盖高频查询的过滤条件
对于上述订单查询场景，status 和 create_time 是核心过滤条件，因此可创建联合索引：
sql
CREATE INDEX idx_orders_status_create_time
ON orders (status, create_time);
创建后再次执行 EXPLAIN，会发现执行计划变为 index_scan，仅扫描符合条件的索引数据，执行耗时降至 100 毫秒以内。 - 避免 “过度索引”，平衡读写性能
索引虽能加速查询，但会增加写入（INSERT/UPDATE/DELETE）的开销 —— 每写入一条数据，TiDB 需维护索引的一致性。因此，需删除业务中未被使用的冗余索引，例如：
sql
DROP INDEX idx_orders_status ON orders; – 若该单字段索引已被联合索引覆盖 - 利用 “前缀索引” 优化长文本字段
若业务中有对长文本字段（如 order_desc）的模糊查询需求，直接索引全字段会占用大量空间。此时可创建前缀索引：
sql
CREATE INDEX idx_order_desc_prefix
ON orders (SUBSTRING(order_desc, 1, 32));
这样既能满足查询需求，又能控制索引存储成本。
三、进阶优化：索引与执行计划的 “深度协同”
除了基础索引设计，还可通过以下技巧进一步压榨性能： - 强制索引选择（谨慎使用）
若 TiDB 优化器未选择最优索引，可通过 USE INDEX 强制指定：
sql
SELECT * FROM orders USE INDEX (idx_orders_status_create_time)
WHERE status = ‘unpaid’ AND create_time > ‘2025-10-01 00:00:00’;
但需注意，这种方式会降低优化器的自主性，仅在特殊场景下使用。 - 结合 TiFlash 实现 “HTAP 场景” 的索引互补
对于需要同时支持高并发事务和复杂分析的场景，可将部分大表的索引同步到 TiFlash 列存引擎。例如，为 orders 表的分析类索引开启 TiFlash 副本：
sql
ALTER TABLE orders SET TIFLASH REPLICA 1;
此时，复杂的聚合查询会自动路由到 TiFlash，避免对行存引擎的性能冲击。
四、总结：索引优化的 “闭环思维”
TiDB 索引优化不是一蹴而就的工作，而是需要形成 “慢查询分析 → 索引设计 → 性能验证 → 持续迭代” 的闭环。在实际业务中，建议定期通过 ANALYZE TABLE 更新表统计信息，让 TiDB 优化器始终基于最新数据选择最优索引，从而实现从 “能跑” 到 “跑得快” 的跨越。
如果你在 TiDB 索引优化中遇到特殊场景或疑难问题，欢迎在社区进一步交流探讨