SQL优化之路

原由

APP所需的数据采集大体已经结束，统计了一下数据条数，它是这样的：

花了大约四分钟，因而我换了个小规模的数据库测试了一下查询：

等了大约秒：

这时候的数据量是多少呢，不到万条。整体数据条数大约在万左右。大概算一下从客户端发出请求到得到返回数据大概须要 分钟 ，我见到的延迟分钟的应用大概是这个了。显然，个人这个数据库查询是有问题滴~

---

继续

那么问题出在哪里呢 ？问题可能出如今不少方面。不妨先放下来看一下别人是怎么实现的。

官方检索耗时大约两秒左右，第一个结果的出现说明采起了前缀索引，必然进行了全表扫描了。那么它的数据规模有多少呢，试一下，大约有 万条。

如今就发现问题所在了，我获取的数据有 万条，可是这里只有 万条，那剩下的 万条去哪里了？ 你猜对了，每一种书都会有不止一本。随便点开搜索结果的一本，果真，馆藏五本。

到此，官方的实现思路就清晰了。 （2U + 16*8内存 + SSD ）的服务器部署 MYSQL + Spring。数据分表，书目表+书详情表。查询的时候先在数据较小的书目表中查询出书的名称，书详情表中对书名创建BTREE索引。这样足以在用户能够接受的时间内完成查询。

优化思路一

创建书目表和书详情表，这样能够把数据规模缩小 ，带来的性能提高仍是很可观的。

果真，此次在万条数据中查询用了秒，已经接近官方的数据了。

优化思路二

放弃前缀模糊匹配

这应该已经脱离优化的范畴了，为了速度而牺牲了数据的准确性。秒的延迟彻底在可接受的范围以内，可是在数据量巨大的状况下，有必要进行前缀后缀匹配吗？以关键词为例，前缀模糊查询耗时秒得到条结果，后缀模糊查询耗时秒得到条结果，相差约条记录。思考一下app开发的初衷:给用户推荐更好的书。一本书质量的最终判断应该交给用户。所以，将用户引导至书架更为重要。因此牺牲一部分准确性是可行的。

优化思路三

删减部分陈旧的书

仍是以为例，在模糊匹配的本书中，出现了大量的这种书：

很明显这一部份书的参考价值已经不大了。以 年为界， 年的书共有 种，即大约有 的书是冗余的。那么数据库的规模又能够缩小一部分，剩余大约28万种。查询时间大概能缩小至 秒。

优化思路四

加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱 ！加钱