从正则搜索重新认识索引从正则搜索重新认识索引

最近一些查询接口加载时间逐渐变长，发现都是因为在筛选条件中有正则搜索，但是这些字段我们也都按照常规的方式设置了索引。而非正则搜索则没有影响，所以最直观的想法是：正则搜索在使用索引的地方不清楚，需要补一补。
什么是索引数据库的核心功能是为了保存数据还有与之对应的对数据操作的能力：增删改查。当数据量逐渐增大，比如用户数量：百万、千万、甚至数亿的时候，我们需要从里面找到一些复合条件的数据就显得很复杂了，当然可以一个一个找，但是相信没人会这么做，因为会非常慢。这个时候怎么办呢？
其实与大家学习数据库时的例子字典，是一样的。我们查找这些数据通常是根据某些特定的条件。比如对于字典，我们通常是通过拼音查找，而不是通过：那些字的词语包含掘金。
那么字典是怎么处理的呢？把我们最常用的搜索条件拼音单独列出来，放在最前面，这样在查字典的时候，就只需要翻前几页就好了，找到需要的字再跳转到对应的页数就可以了。索引是什么呢？
索引就是：将部分字段值取出来，单独维护成一个查询很快的数据结构。
索引原理
这个查询很快的数据结构简单的来说就是创建一颗树（树直观点就比较像嵌套很多的json）。当然这颗树为了查询数据，做了很多优化，其模样就像这样下方图片一样。具体的算法名称：B+ Tree，大家可以去了解一下。这样我们在查询的时候，就相当于二分法猜数字一样，很快就能定位到数据，即便上亿的数据也很快。

文章图片

那为什么正则搜索加了索引还是很慢呢？
正则搜索过程如果我们仔细想一下，就会发现其实很简单。因为索引的原理就是将这个字段的值，单独拿出来，按照更快的查找格式存储起来。索引查找的过程就是，直接对新建立的数据比较就好了。但是正则不是简单的比较大小，还需要运算才知道最终的结果。所以对于加了索引的正则匹配（模糊匹配类似），也还是会将所有内容一个一个的进行正则运算完才会有结果，这自然非常慢了。
结论大概就是这样，下面我使用 mongodb 看看实际过程。一般的查询索引都是 B+ Tree，mongodb、sql也是，所以是想通的。
mongo 的数据测试

# 查看测试数据总数 db.game.count(); # 50407 条数据# mongo获得查询过程的方法是添加 explain 就好了 db.game.find({"name":"麻辣英雄"}).explain("allPlansExecution");

数据结构

{ "_id": "5590b3f9bac548696b8b45cf", "des": "《麻辣英雄》是一款历史大乱斗题材的半即时制RPG手游。高精度还原长城、皇宫等场景，百类Q萌武将，千种英雄组合，独创主角技能，更有巨型BOSS战、攻城战等特色玩法，让手游告别无趣", "name": "麻辣英雄", "download": 1 // 还有很多其他字段 }

避免结果太长，删除了大部分过程解释。只留下了关键的几个数据。查询命令如下：

普通查询 db.game.find({"name":"麻辣英雄"}).explain("allPlansExecution");
正则查询 db.game.find({"name":/麻辣英雄/}).explain("allPlansExecution");

各种情况测试结果不加索引+普通查询

[ { "executionStats": { "executionSuccess": true, "nReturned": 1, "executionTimeMillis": 20, "totalKeysExamined": 0, "totalDocsExamined": 50407, } } ]

不加索引+正则查询

[ { "executionStats": { "executionSuccess": true, "nReturned": 1, "executionTimeMillis": 31, "totalKeysExamined": 0, "totalDocsExamined": 50407, } } ]

添加索引+普通查询

[ { "executionStats": { "executionSuccess": true, "nReturned": 1, "executionTimeMillis": 0, "totalKeysExamined": 1, "totalDocsExamined": 1, } } ]

添加索引+正则查询

[ { "executionStats": { "executionSuccess": true, "nReturned": 1, "executionTimeMillis": 40, "totalKeysExamined": 50407, "totalDocsExamined": 1, } } ]

汇总由解释结果的 executionSuccess 与 nReturned 可知，均成功返回了一条数据。然后其主要过程分别是：查询过程中索引与文档扫描的数量。

标题	索引扫描行数	文档扫描行数	执行耗时
无索引普通查询	0	50407	20
无索引正则查询	0	50407	30
有索引普通查询	1	1	0
有索引正则查询	50407	1	40

没有添加索引就会全表扫描，一个一个去读取原始数据-文档。一般可认为是存放在硬盘中的，硬盘读取可是比内存慢超多的。此处没有特别慢可能是数据太少，缓存在内存中了。
加了索引之后就会发现，文档扫描部分都是1，所以索引匹配过程都是在单独构建的数据结构上面，降低了大量的硬盘读写。
但是加了索引，正则还是扫描了全部字段，只不过此时就是使用的索引这个结构保存的字段，而不是从磁盘读取。因为正则只有匹配了才知道结果，所以还是会很慢，底层一切都是简单编程操作，没有黑魔法。

索引大小

文章图片

上方是测试数据的情况，所有数据大小 127M，desc 的索引（描述文本）就有 42.8M。而 download 数字类型的索引只有 221.2KB 。
从大小我们也可以看出，索引建立是需要单独存放一次数据的，所以对于文本字段建立所以一定需要考虑清楚。对于大文本建立索引有一下问题：

索引本身可能是意义不大，因为对于大文本一般都是为了模糊匹配
会导致索引过大，可能内存都不能一次加载完成，那么速度会更加慢

有什么收获呢索引本身没有什么黑魔法，简单的来讲就是冗余查询条件的部分数据，将其构造成更加复合查询的结构，这样就能解决一般情况下超大数据的查询性能问题。
正则查询或者模糊匹配之类，也没有其他优化，数据库查询也就像写普通代码一样，只有当代码真正执行才知道结果，所以需要慎重使用，特别是对于应用端的接口！那需要搜索怎么办呢？
模糊搜索权重排序这些一般都属于：全文搜索。全文搜索的数据库会采用完全不同的方案去处理模糊搜索，其基基本逻辑是：