特殊索引类型

位图索引与差分索引的高效应用
  1. 位图索引
    • 也称bitmap索引。该索引主要针对DF(文档频率)非常高的term,比如“的”(如果它不是一个停用词的话)。它用一个位来表示是否在某个文档中出现,因此,对于总文档数为N的索引库,每个term对应的索引大小为N/8
  2. 差分索引
    • 普通索引中,文档ID使用u_int表示。对于索引比较长的term,其连续两个文档ID之间的差通常比较小,因此可以采用记录差值来代替记录ID,并且使用特定的编码(比如huffman编码)使得小数字占用更少的位。以此来减少索引的大小
  3. 压缩索引
    • 压缩索引通常针对于索引较长的term,它将其中次要的一些信息剔除,仅保留文档ID。这些信息可能包括文档相关的、用于过滤或类聚的属性(比如文档签名),这些信息通常可以存放在另外一个单一的结构中,减少信息重复。offset信息也可以被剔除。
    • 截断索引
      • 在使用offset等信息的索引中,索引会比较大,而位图、压缩索引中又丢失了这些信息,因此考虑考虑一个折中,保留一定长度的记录了这些信息的索引。保留的原则是选择当前可决定的权值较高的文档(比如TF较大)。这种索引称为截断索引。
    • 预索引
      • 对于一些静态数据的检索系统,可以将检索高频词预先检索一遍,得到结果并存储为新的索引文件,称为预索引。查询时如果命中,可以直接读取预索引的数据。这种索引从本质上将相当于基于硬盘的cache

<think>嗯,用户这次明确想了解MySQL的索引类型及其特点和应用场景。从用户引用的资料来看,ta已经查阅过一些专业文档,包括索引类型概述、具体存储引擎比较等,说明用户可能正在做数据库性能优化相关的工作,或是准备技术面试。 用户引用的四份资料中,[1]和[2]详细介绍了索引类型,[3]提到存储引擎对索引的影响,[4]则强调主键索引的特性。需要特别注意:不同存储引擎支持的索引类型确实不同,比如InnoDB不支持Hash索引(除非显式创建自适应哈希),而Memory引擎默认就用Hash索引。 用户可能存在的深层需求:ta可能实际遇到了查询性能问题,想通过选择合适的索引类型来解决。比如当ta的查询中频繁出现范围查找时,B-Tree索引会比Hash索引更合适;或者当处理全文搜索需求时,需要了解FULLTEXT索引特殊性。 在整理回答时需要突出三点:一是类型之间的核心差异(如B-Tree的范围查询支持 vs Hash的等值查询优势),二是存储引擎的兼容性说明(这是很多文档容易忽略的点),三是典型错误用法示例(比如在B-Tree索引列上用函数导致失效)。用户上次优化SQL的对话表明ta对实践细节很关注。 最后补充的四个问题也经过斟酌:"前缀索引长度"是索引优化的常见痛点,"强制索引"适用于紧急优化场景,"索引维护"涉及长期性能,"索引失效"则是调试高频问题——这些都和用户当前的索引研究强相关。</think>以下是对MySQL索引类型的详细说明,包含特点、适用场景及存储引擎支持情况: --- ### 一、核心索引类型及特点 | **索引类型** | **数据结构** | **查询支持** | **存储引擎支持** | **特点总结** | |--------------|------------------|-----------------------------|-----------------------------|-----------------------------| | **B-Tree** | 平衡多路搜索树 | ✅ 精确查询<br>✅ 范围查询<br>✅ 排序<br>✅ 前缀匹配(`LIKE 'abc%'`) | InnoDB、MyISAM、Memory等 | 最通用索引,默认索引类型[^1][^2] | | **Hash** | 哈希表 | ✅ 精确等值查询<br>❌ 范围查询<br>❌ 排序 | Memory引擎默认<br>InnoDB(自适应哈希) | 等值查询O(1)复杂度,内存利用率高[^2][^3] | | **Fulltext** | 倒排索引 | ✅ 全文搜索<br>✅ 自然语言处理<br>✅ 布尔搜索 | InnoDB ≥5.6<br>MyISAM | 支持`MATCH() AGAINST()`语法[^1] | | **R-Tree** | 空间树结构 | ✅ 地理空间查询<br>✅ 范围交集判断 | MyISAM(默认)<br>InnoDB ≥5.7 | 专用于GIS数据类型(`GEOMETRY`, `POINT`等)[^3] | --- ### 二、特殊索引类型 | **索引类型** | **本质** | **特点** | **创建方式** | |----------------|-----------------|-----------------------------------------|--------------------------------| | **主键索引** | 特殊的唯一索引 | 🔑 不允许NULL值<br>🔑 表只有一个主键索引<br>🔑 物理存储按主键顺序组织(InnoDB聚簇索引) | `CREATE TABLE(... PRIMARY KEY)` | | **唯一索引** | 约束型索引 | 🔒 保证列值唯一性<br>🔒 允许NULL值(InnoDB允许单个NULL) | `CREATE UNIQUE INDEX ...` | | **组合索引** | 多列B-Tree索引 | 📚 遵循最左前缀原则<br>📚 可覆盖多列查询条件 | `CREATE INDEX idx ON t(col1,col2)` | --- ### 三、应用场景对比 | **场景** | **推荐索引** | **原因说明** | |------------------------------|-----------------|----------------------------------------------------------------------------| | 用户ID精确查询 | Hash索引 | 等值查询速度极致优化(Memory引擎)[^2] | | 订单时间范围筛选 | B-Tree索引 | 范围查询和排序高效支持[^1] | | 商品名称全文搜索 | Fulltext索引 | 支持语义分析和关键词权重排序[^1] | | 地理位置附近商家查询 | R-Tree索引 | 空间关系计算效率远超B-Tree[^3] | | 用户登录(邮箱+密码验证) | 组合索引 | 对`(email,password)`建索引可覆盖查询,避免回表 | --- ### 四、各存储引擎索引支持差异 | **存储引擎** | **B-Tree** | **Hash** | **Fulltext** | **R-Tree** | **特性说明** | |--------------|------------|----------|--------------|------------|--------------------------------| | **InnoDB** | ✅ 主键即聚簇索引 | ✅ 自适应哈希(内部优化) | ✅ ≥5.6 | ✅ ≥5.7 | 支持事务,行级锁[^3] | | **MyISAM** | ✅ | ❌ | ✅ | ✅ | 表级锁,非事务安全 | | **Memory** | ✅ | ✅ 默认 | ❌ | ❌ | 数据存内存,重启丢失[^3] | --- ### 五、使用示例 #### 1. B-Tree索引(范围查询) ```sql -- 创建索引 CREATE INDEX idx_price ON products(price); -- 高效执行 SELECT * FROM products WHERE price BETWEEN 100 AND 500 ORDER BY price DESC; -- 利用索引排序 ``` #### 2. Fulltext索引(文本搜索) ```sql ALTER TABLE articles ADD FULLTEXT ft_index(title, content); -- 自然语言模式搜索 SELECT * FROM articles WHERE MATCH(title,content) AGAINST('数据库优化' IN NATURAL LANGUAGE MODE); ``` #### 3. 自适应哈希(InnoDB自动启用) ```sql -- 无需手动创建,当某索引被频繁访问时自动构建 SHOW ENGINE INNODB STATUS; -- 查看哈希索引使用情况 ``` --- > **关键注意事项**: > 1. **索引选择误区**: > - ❌ 盲目创建Hash索引:仅Memory引擎显式支持,InnoDB需通过`innodb_adaptive_hash_index`参数启用自适应[^3] > - ❌ 全文索引替代普通索引:Fulltext仅用于文本搜索,常规查询仍需B-Tree > 2. **组合索引设计**: > ```sql > -- 有效使用索引场景 > CREATE INDEX idx_user ON orders(user_id, status, create_time); > /* 可加速: > WHERE user_id=1 > WHERE user_id=1 AND status='paid' > WHERE user_id=1 ORDER BY create_time > */ > ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值