网站平台架构演变史 - 数据库表的查询优化

Posted 2020-09-16 风间影月の技术小站

上篇说道了数据库读写分离，对于大型网站来说这么说是十分有必要的。数据库在整个互联网架构中担当的角色无法有两个，存储和运算，很多时候这两个是并存的，但是在后期，对于上亿条数据来说，让数据库既要存储，又要运算，那么是这是不可行的，为了保证性能，我们仅仅只需要最大化利用DB的存数就行了，连数据库之间的外键管理都不需要，只要有对应的id即可。那么既然如此，相互关联的表肯定会存在删除业务，而事实上我们如今处理删除操作并不是真正的删除，只不过我们添加了is_delete这个字段来标注逻辑是否删除即可。不然在表关联的时候可能会查询不到对应的数据。

如下最重要的用户表中的记录就是绝对不能删除的

举个栗子，我们办理信用卡后会有对应银行中的一个账户，就算你不用卡了，销卡注销了，那么你的账户记录还是会存在的，只不过标志位更改了而已。曾经我有张工行的信用卡，后来不用了，于是在我注销的第二个月我还款错了，但是没有提醒我此卡已经注销，还是照样把钱打了进去，于是就只能很麻烦的跑到总行去走流程把钱取出来了。。。

（注：有些表中的记录可以直接删除的，比如无所谓的消息表，公告表，这些数据在过期后是不会用到的，那么删了也无所谓）

大数据量的情况下查询怎么做？

这里举两个栗子：

1、商品表，我们在电商平台查询商品的时候，其后台并没有真正的去数据库查询，比如淘宝的店铺就有上千万家甚至更多，每家店铺发布的商品又是数以万计，那么商品表中的数据就十分庞大了，直接查询肯定会受到性能影响，那么这个时候不论做水平拆分还是垂直拆分，最终要做的就是使用搜索引擎技术，比如solr或者ES，这样每次查询的时候都是去文件系统中找对应的索引，这样效率会十分高，商品表对于读写来说，写明显要比读要来的多，那么在这种情况下使用搜索引擎是理想的。

2、交易记录表，对于交易来说，每天的交易量也会很多，这个时候很大的情况下会进行数据迁移，也就是水平分表，参照京东的设计，在查询交易的时候把时间分为了多个维度，也就是查询的时候其实是进行了不同表之间的查询，这样可以加速了查询效率。只不过要设定某一时间要进行不同表之间的数据同步以及切换

总结，查询效率的提示本质上是缩小查询范围，范围小了，效率就上去了。水平拆分以及垂直拆分要根据实际情况的业务来进行，不能随意。