一、当索引遇到数据偏科现场
老王最近接手了一个电商系统，用户表里有个province省份字段建立了普通索引。但当查询浙江省用户时响应飞快，查西藏用户却慢如蜗牛。通过EXPLAIN发现两种查询都走了索引，但执行时间相差50倍。这种典型的索引失效场景，正是我们今天要讨论的索引字段值分布不均问题。
1.1 索引的工作原理复习
MySQL的B+树索引就像图书馆的图书索引卡，当我们要找某类图书时：
-- 假设存在age字段的索引
SELECT * FROM users WHERE age = 25;
索引会先定位到25岁的索引条目，再通过指针找到对应数据。这种机制在数据均匀分布时非常高效，但当某个值占比过高时...
1.2 数据偏科的三种典型场景
（1）状态类字段：订单表的status字段，90%记录都是"已完成"
（2）地区字段：用户地域集中在个别省份
（3）时间字段：日志表最近三个月数据占80%
二、从真实案例看问题本质
2.1 订单状态查询困境
-- 创建测试表（MySQL 8.0）
CREATE TABLE orders (
id INT PRIMARY KEY,
status ENUM('pending','shipped','completed') NOT NULL,
created_at DATETIME,
INDEX idx_status (status)
) ENGINE=InnoDB;
-- 插入模拟数据（100万订单）
INSERT INTO orders
SELECT
n,
CASE
WHEN n%100 < 90 THEN 'completed'
ELSE IF(n%2, 'pending', 'shipped')
END,
NOW() - INTERVAL FLOOR(RAND()*365) DAY
FROM
nums; -- 假设nums是数字辅助表
当查询少量未完成订单时：
EXPLAIN
SELECT * FROM orders
WHERE status = 'pending'
AND created_at > '2023-01-01';
虽然走了索引，但需要回表读取大量无效记录。优化器估算后发现需要回表9万次（总记录数×选择率），还不如全表扫描。
2.2 执行计划深度解析
对比两个查询的执行计划差异：
-- 查询高频值（completed）
EXPLAIN
SELECT SQL_NO_CACHE *
FROM orders
WHERE status = 'completed'
LIMIT 100;
-- 查询低频值（pending）
EXPLAIN
SELECT SQL_NO_CACHE *
FROM orders
WHERE status = 'pending'
LIMIT 100;
虽然都显示使用索引，但观察rows字段会发现：
- 高频值查询预估扫描行数接近全表
- 低频值查询预估准确
三、五大优化方案实战
3.1 方案一：索引合并策略
通过组合索引包含更多过滤条件：
ALTER TABLE orders
ADD INDEX idx_status_created(status, created_at);
此时执行：
EXPLAIN
SELECT * FROM orders
WHERE status = 'pending'
AND created_at > '2023-01-01';
索引同时覆盖status和时间条件，回表次数从9000次降到300次。
3.2 方案二：直方图统计（MySQL 8.0+）
当无法修改索引结构时：
ANALYZE TABLE orders
UPDATE HISTOGRAM ON status WITH 10 BUCKETS;
这会帮助优化器准确估算不同status值的分布，选择更优的执行计划。
3.3 方案三：分区表应用
对日志类时间偏科数据：
CREATE TABLE logs (
id INT AUTO_INCREMENT,
log_time DATETIME,
content TEXT,
PRIMARY KEY (id, log_time)
) PARTITION BY RANGE COLUMNS(log_time) (
PARTITION p2022 VALUES LESS THAN ('2023-01-01'),
PARTITION p2023 VALUES LESS THAN ('2024-01-01')
);
查询最近数据时只需扫描单个分区。
3.4 方案四：引入散列字段
对于高度集中的用户省份：
ALTER TABLE users
ADD COLUMN province_hash TINYINT
GENERATED ALWAYS AS (CRC32(province)%10) STORED,
ADD INDEX idx_prov_hash(province_hash);
SELECT * FROM users
WHERE province = '浙江'
AND province_hash = 3; -- 已知浙江的哈希值为3
通过哈希桶将查询分散到不同数据块。
3.5 方案五：强制索引提示
在明确知道最优路径时：
SELECT * FROM orders
FORCE INDEX (idx_status_created)
WHERE status = 'pending';
但要注意数据分布变化可能导致提示失效。
四、技术方案选型指南
4.1 各方案适用场景对比
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 复合索引 | 存在可组合的查询条件 | 查询效率显著提升 | 增加索引维护成本 |
| 直方图统计 | 无法修改表结构 | 无需物理变更 | 仅优化估算准确性 |
| 分区表 | 时间范围查询场景 | 物理隔离数据 | 分区策略需谨慎设计 |
| 哈希字段 | 离散值且分布稳定 | 均衡数据分布 | 增加存储和维护成本 |
| 强制索引 | 明确知道最优路径 | 立即生效 | 需要持续监控数据变化 |
4.2 避坑指南
- 索引维护成本陷阱：每个新增索引会使写操作增加约10%的耗时
- 直方图更新策略：建议在数据变化超过20%时重新收集统计信息
- 分区表使用限制：唯一索引必须包含分区键
- 哈希字段注意事项：桶数量建议为质数，避免哈希冲突
五、最佳实践与未来展望
5.1 监控体系建设
配置慢查询日志定期分析：
# my.cnf配置
slow_query_log = 1
long_query_time = 1
log_queries_not_using_indexes = 1
结合Percona Toolkit进行日志分析。
5.2 自适应优化趋势
MySQL 8.0的不可见索引功能：
ALTER TABLE orders
ALTER INDEX idx_status INVISIBLE;
可先创建索引进行测试，验证有效后再正式启用。
5.3 云数据库新特性
阿里云RDS的索引推荐引擎，可自动分析SQL模式并生成优化建议，大幅降低人工优化成本。
六、总结升华
索引优化本质是数据分布的博弈。当遇到值分布不均时，不要急于否定索引的价值，而应该像老中医把脉般分析具体症状。记住三个关键原则：
- 让查询条件尽可能确定少量数据
- 使索引覆盖完整的查询逻辑
- 定期复查优化效果
通过本文的多个实战方案，我们可以根据具体业务场景选择合适的武器。但更重要的是建立持续优化的意识，毕竟数据分布就像天气——永远在变化，需要持续观察和调整。