数据库索引类型有哪些?

哎，数据库索引这事儿，上周有客户问我，搞得我都有点忘了。
你说的这两种索引类型，我帮你捋捋哈。

稠密索引吧，说白了就是数据库里每一行数据，只要索引列有值，就一定在索引里占个位置，记录着它在磁盘上的具体地址。
比如你在淘宝查某个宝贝，你输入关键词，系统直接通过索引找到宝贝的存储位置，嗖一下就给你出来了。
这种索引最大的好处就是查得快，特别适合那种字段值特别多、很少重复的列，比如订单号、用户ID这种。
但是！缺点也很明显，索引本身占空间啊，你表里有1 00万条数据，索引也得跟着有1 00万条记录，内存和硬盘压力都不小。

稀疏索引呢，思路就不一样了。
它不是给每条数据都建索引，而是把数据分块，比如每1 000条数据作为一个块，然后只给每个块建立一个索引记录，这个记录会告诉你这个块大概在哪。
你要查数据的时候，先通过稀疏索引找到对应的块，然后进去挨个儿找。
就像找书，你先翻目录知道大概在哪一章，然后进去一章一章看。
这种索引最大的好处就是省空间，尤其数据量特别大的表，索引文件能小很多。
但缺点就是查起来慢点儿，特别是你要找的数据刚好在那个块的边缘，你可能得把整个块的数据都扫一遍。

我之前在处理一个亿级别的用户表，用户ID是自增的，我们用稠密索引，查用户信息那叫一个快。
但有个朋友的系统，他那个表的某个字段选择率特别低，重复值多，最后用了稀疏索引，空间省了不少，但有时候查起来真够呛。

所以啊，选哪种索引，得看你具体情况。
啥字段经常查？数据量有多大？空间和速度你更看重哪个？这都得权衡。
反正没有绝对的好坏，看你怎么用吧。

数据库索引类型有哪些?

说实话，我当年刚摸数据库那会儿，对索引的理解就是"加个东西让找数据快"，后来慢慢发现没那么简单。
稠密索引和稀疏索引这俩玩意儿，真挺有意思的。

我碰见过一个案例，某电商公司做促销活动，突然查用户订单量暴涨。
结果系统卡得像死，一查发现是没给订单ID建索引。
你想想，订单表几百万条数据，每次都得全表扫描，这能不慢吗？这时候稠密索引就派上用场了——订单ID上建稠密索引，每个ID都直接对应索引条目，查起来快得飞起。

但稠密索引也有坑。
我之前维护过一个旧系统，用户表按生日建稠密索引，结果内存吃紧。
为啥？因为每天过生日的人可能就那么几个，但索引条目却为每个过生日的人都留了位置。
这就像你给全班同学都建了生日索引，哪怕只有一个人过生日，索引也得占全班的存储空间。
这就是稀疏索引的优势——按块建索引，不是每个数据都有索引，空间利用率高。
不过，稀疏索引在查找时可能得多跳几步，像你说的先定位到块，再顺序查找。

我有个朋友做金融系统，他给我讲过选择率这个概念。
他说他们系统查用户交易记录，交易ID的选择率接近0.1 %，意思就是每1 000条记录里大概有1 条重复。
这种情况下，稠密索引就太浪费了，用稀疏索引更合适。
选择率越低，稀疏索引越划算。
当然，他最后加了点聪明劲儿，对高频查询的ID段用稠密索引，其他用稀疏，效果还真不错。

维护成本这点也挺现实。
我修过几个老系统，索引没少崩溃。
每次数据大更新，DBA就得加班加点重建索引。
有回我亲眼看见，一个千万级表的索引重建，搞了快半夜。
你说这人力成本，是不是得算进总成本里？所以现在我们系统，索引设计前都得盘算盘算维护代价。

说到底，索引就像菜刀——用对了切菜快，用不好可能伤到手。
关键得了解业务场景，比如你是做秒杀还是做报表。
秒杀场景要速度，报表场景要空间，得两权相害取其轻。
我最近接触的几个新系统，都把索引设计当独立模块，专门有人负责，看来这事儿真挺复杂的。

什么是索引?数据库中有哪些索引?各有什么特点?

B树索引：常见，有序，快速定位。
MySQL InnoDB默认B+树，高效范围查询排序。

哈希索引：哈希表实现，等值查询快。
不适合范围查询，不支持部分匹配排序。

位图索引：少量唯一值列有效。
大量重复值高效。
大量唯一值会很大，效率低。

特殊索引：空间索引，地理空间数据。
全文索引，文本搜索。

选择索引看数据特性和查询需求。