当前位置: 首页 > news >正文

面试题记录:分库分表

分库分表的原因:
超大规模数据量导致数据查询慢,关联查询慢

垂直:按照表字段进行处理
水平:按照数据行进行处理

垂直分库
按业务模块切分数据库,例如将用户、订单、商品等业务表独立存储在不同库中。‌‌
‌优点‌:业务解耦、降低单库连接压力、支持独立优化硬件资源。
‌缺点‌:无法解决单表数据量过大问题,跨库事务复杂且无法直接 JOIN

垂直分表
将大表按字段访问频率拆分,例如主表存核心字段(如用户 ID、姓名),扩展表存低频字段(如地址、简介)。‌‌
‌优点‌:减少单行数据 I/O 压力,提升高频字段查询效率。
‌缺点‌:需管理表关联,查询完整数据需 JOIN 操作。‌‌

水平分库
按分片键(如用户 ID、时间)将同一表数据分布到多个库,库结构相同(如按哈希取模或数值范围划分)。‌‌
‌适用场景‌:单表数据量极大且并发压力高,例如电商订单表。
‌挑战‌:跨库事务一致性、全局主键生成、扩容需数据迁移。‌‌

‌水平分表‌
将单表数据按规则拆分到同库多个表中(如表名后缀按哈希分布)。
‌适用场景‌:数据量未达分库阈值但单表性能瓶颈明显。
‌局限‌:无法缓解单机硬件资源竞争,建议优先分库。‌‌

工具与方案选择
‌ShardingSphere/ShardingJDBC‌:通过中间件实现透明化分片,支持自定义分片策略,减少代码侵入性。‌‌
‌MySQL 分区表‌:内置水平分区功能(如按 RANGE、HASH 分区),但仅限单库内分表,无法解决分布式扩展问题。‌‌

http://www.wxhsa.cn/company.asp?id=8

相关文章:

  • 2025年物流行业CRM解决方案全解析:数字化时代的客户关系管理新范式 - SaaS软件
  • CentOS 上独立编译 Linux 内核一般性流程
  • 西门子分布式IO从站与主站的PN连接
  • 为时序数据库 IoTDB 底层架构“保驾护航”,来听听新晋 Committer 的贡献心路!
  • VU9P板卡设计方案:565-基于VU9P的32@ SFP28+4@ QSFP28路光纤交换板卡
  • 微信小程序语音转文字(插件:微信同声传译)
  • 黑产群控日损百万?设备ID乱象要如何终结?