一、索引设计的核心矛盾
在数据库系统中，索引就像图书馆的目录卡片，能快速定位到具体数据。但设计不当的索引，反而会成为累赘。OceanBase 作为一款分布式数据库，面临着比单机数据库更复杂的索引管理问题。这里存在三个核心矛盾：
- 高选择性：索引列的值越唯一，过滤效果越好。比如身份证号字段比性别字段更适合建索引。
- 低维护成本：每次数据变更都需要同步更新索引，在分布式环境下代价更高。
- 查询覆盖：理想情况下索引能直接返回查询所需数据，避免回表操作。
-- OceanBase 示例：创建高选择性索引
CREATE INDEX idx_user_idcard ON users(id_card); -- 身份证号唯一性高
CREATE INDEX idx_user_gender ON users(gender); -- 性别只有2-3种枚举值，选择性低
二、高选择性的实战策略
高选择性索引能显著提升查询效率，但需要精准选择字段。以下是典型场景：
场景1：唯一标识字段
用户ID、订单号等具有天然唯一性的字段是首选。OceanBase 的全局索引特性尤其适合此类场景：
-- 创建全局唯一索引（OceanBase 特有语法）
CREATE UNIQUE GLOBAL INDEX idx_order_no ON orders(order_no) PARTITION BY HASH(order_no);
场景2：组合字段提升选择性
单个字段选择性不足时，可通过组合多列提升：
-- 组合城市+街道+门牌号作为地址索引
CREATE INDEX idx_composite_addr ON addresses(city, street, door_number);
注意：OceanBase 的局部索引（LOCAL INDEX）会随主表分区，适合分区键相同的查询场景。
三、控制维护成本的技巧
索引维护成本在频繁写入的场景下尤为突出。以下是优化方案：
方案1：延迟维护
OceanBase 支持异步索引维护，适合批量导入场景：
-- 设置索引延迟维护（OceanBase 4.x+）
ALTER TABLE orders DELAY_KEY_WRITE = ON;
方案2：部分索引
只为特定数据子集创建索引：
-- 只为活跃用户创建索引
CREATE INDEX idx_active_users ON users(user_id) WHERE status = 'active';
方案3：冷热数据分离
将历史数据迁移到历史表，减少主表索引负担：
-- 按月分区的订单表设计
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
order_date DATETIME
) PARTITION BY RANGE (UNIX_TIMESTAMP(order_date)) (
PARTITION p202301 VALUES LESS THAN (UNIX_TIMESTAMP('2023-02-01')),
PARTITION p202302 VALUES LESS THAN (UNIX_TIMESTAMP('2023-03-01'))
);
四、查询覆盖的极致优化
覆盖索引能避免回表操作，是性能优化的杀手锏。OceanBase 的存储引擎特性使其在这方面表现优异：
最佳实践1：INCLUDE 子句
OceanBase 3.x 开始支持包含非索引列：
-- 包含查询所需的额外列
CREATE INDEX idx_cover_order ON orders(user_id) INCLUDE (amount, create_time);
最佳实践2：聚簇索引设计
主键聚簇索引天然具备覆盖特性：
-- 按最常查询的字段设计主键
CREATE TABLE orders (
user_id BIGINT,
order_no VARCHAR(32),
PRIMARY KEY (user_id, order_no) -- 联合主键聚簇
);
最佳实践3：物化视图
对于复杂查询，可使用 OceanBase 的物化视图：
-- 创建每日销售额物化视图
CREATE MATERIALIZED VIEW mv_daily_sales
REFRESH COMPLETE ON DEMAND
AS SELECT DATE(create_time) AS day, SUM(amount)
FROM orders GROUP BY day;
五、真实场景下的平衡案例
电商订单查询优化
需求：同时支持按订单号精确查询和按用户分页查询：
-- 最终设计方案
CREATE TABLE orders (
order_no VARCHAR(32) PRIMARY KEY,
user_id BIGINT,
INDEX idx_user_orders (user_id, create_time DESC) LOCAL -- 用户维度查询
) PARTITION BY HASH(order_no) PARTITIONS 16;
-- 查询示例1：精确查找
SELECT * FROM orders WHERE order_no = 'EB12345678';
-- 查询示例2：用户分页
SELECT * FROM orders
WHERE user_id = 10086
ORDER BY create_time DESC
LIMIT 10 OFFSET 20;
这个设计实现了：
- 订单号查询通过主键直达
- 用户维度查询通过局部索引避免全局扫描
- 排序字段内置在索引中避免 filesort
六、避坑指南
- 分布式事务陷阱：全局索引可能跨分区，慎用在高频更新场景
- 空间换时间：大文本字段建索引需评估存储成本
- 监控策略：定期检查索引使用率，删除无用索引
-- 查询未使用的索引（OceanBase 信息视图）
SELECT * FROM oceanbase.CDB_INDEX_STATS
WHERE name NOT LIKE 'PRIMARY%'
AND rows_read = 0;
七、总结
在 OceanBase 中设计索引，本质是在做三道选择题：
- 选择战场：识别真正需要加速的查询路径
- 选择武器：用组合索引、覆盖索引等不同策略应对不同场景
- 选择代价：评估维护成本与查询收益的平衡点
好的索引设计不是一蹴而就的，需要结合业务特点持续调优。记住：没有最好的索引，只有最适合当前业务阶段的索引方案。
评论