如果系统处于高速发展阶段,拿商城系统来说,一天下单量可能几十万,那数据库中的订单表增长就特别快,增长到一定阶段数据库查询效率就会出现明显下降。因此,当单表数据增量过快,超过 500 万的数据量就要考虑分表了。
如果系统处于高速发展阶段,拿商城系统来说,一天下单量可能几十万,那数据库中的订单表增长就特别快,增长到一定阶段数据库查询效率就会出现明显下降。
因此,当单表数据增量过快,超过 500 万的数据量就要考虑分表了。
那如何分表呢?
分表有几个维度,一是水平拆分和垂直拆分,二是单库内分表和多库内分表。
就拿用户表(user)来说,表中有 7 个字段:id,name,age,sex,nickname,description,如果 nickname 和 description 不常用,我们可以将其拆分为另外一张表:用户详细信息表,这样就由一张用户表拆分为了用户基本信息表+用户详细信息表,两张表结构不一样相互独立。但是从这个角度来看垂直拆分并没有从根本上解决单表数据量过大的问题,因此我们还是需要做一次水平拆分。
拆分表
还有一种拆分方法,比如表中有一万条数据,我们拆分为两张表,id 为奇数的:1,3,5,7……放在 user1 中, id 为偶数的:2,4,6,8……放在 user2 中,这样的拆分办法就是水平拆分了。
水平拆分的方式有很多,除了上面说的按照 id 拆表,还可以按照时间维度去拆分,比如订单表,可以按每日、每月等进行拆分。
总结一下水平拆分和垂直拆分的特点:
拿水平拆分为例,每张表都拆分为了多个子表,多个子表存在于同一数据库中。比如用户表拆分为用户 1 表、用户 2 表。
单库拆分
在一个数据库中将一张表拆分为几个子表在一定程度上可以解决单表查询性能的问题,但是也会遇到一个问题:单数据库存储瓶颈。
所以在业界用的更多的还是将子表拆分到多个数据库中。比如下图中,用户表拆分为两个子表,两个子表分别存在于不同的数据库中。
多库拆分
一句话总结:分表主要是为了减少单张表的大小,解决单表数据量带来的性能问题。
延伸阅读:
答案很简单:数据库出现性能瓶颈。用大白话来说就是数据库快扛不住了。
数据库出现性能瓶颈,对外表现有几个方面:
在高并发场景下,大量请求都需要操作数据库,导致连接数不够了,请求处于阻塞状态。
如果数据库中存在一张上亿数据量的表,一条 SQL 没有命中索引会全表扫描,这个查询耗时会非常久。
业务量剧增,单库数据量越来越大,给存储造成巨大压力。
从机器的角度看,性能瓶颈无非就是 CPU、内存、磁盘、网络这些,要解决性能瓶颈最简单粗暴的办法就是提升机器性能,但是通过这种方法成本和收益投入比往往又太高了,不划算,所以重点还是要从软件角度入手。
最后建议,企业在引入信息化系统初期,切记要合理有效地运用好工具,这样一来不仅可以让公司业务高效地运行,还能最大程度保证团队目标的达成。同时还能大幅缩短系统开发和部署的时间成本。特别是有特定需求功能需要定制化的企业,可以采用我们公司自研的企业级低代码平台:织信Informat。 织信平台基于数据模型优先的设计理念,提供大量标准化的组件,内置AI助手、组件设计器、自动化(图形化编程)、脚本、工作流引擎(BPMN2.0)、自定义API、表单设计器、权限、仪表盘等功能,能帮助企业构建高度复杂核心的数字化系统。如ERP、MES、CRM、PLM、SCM、WMS、项目管理、流程管理等多个应用场景,全面助力企业落地国产化/信息化/数字化转型战略目标。 版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们微信:Informat_5 处理,核实后本网站将在24小时内删除。版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系邮箱:hopper@cornerstone365.cn 处理,核实后本网站将在24小时内删除。