除了正常的单 数据库设计，可能会因为数据库的数据量的增长，导致性能低下
1.读写分离：就是解决读多写少的，
实现原理：主库写，从库读
可能问题：
数据同步问题，可能主库的数据要同步到从库 需要1s，如果写操作之后 立刻读，可能会存在查不到数据的情况
解决办法：3种
那个库写的 就哪个库读（业务耦合度太高）
如果查询错误，再查另外一个库（增加性能损耗）
最好的办法：根据关键业务 和 非关键业务 区分，关键业务，就都用主库，非关键业务 就读写分离，这种也要根据业务场景
2.分库分表
分库
分库：就是一个库 分为 多个数据库，解决的是数据库 存储位置的问题，
应用场景 数据库 总体数据过多
可能的问题：
分库之后可能会有 分布式事务问题
解决办法：分布式事务框架，后续会有详细文档
join查询问题：
解决办法：只能单独查询 然后去B库 再查询
分表：就是单表的数据量过大，需要分表
分为
垂直分表：就是字段拆分
应用场景：字段过多，需要根据业务 表来进行拆分，进行管理
水平分表：就是数据量的拆分
应用场景：因为单表数据量过大，进行拆分，提升性能
方式：
id拆分;有点：水平扩展方便，只需要添加表 缺点：数据的不平均
hash拆分（推荐）：优点：数据平均 缺点：表的扩展不方便
表的扩展不方便 解决办法：
加一张扩展表（id，hash值，对应的表），可能还会有问题，因为如果这个表 数据量过大，我们又要进行分表操作，这是一个死循环
解决办法：只能，添加索引，所以还是hash算
join问题：数据分散在多表中，如果需要与其他表进行join查询，需要再业务代码或数据库中间件中进行多次join操作
count问题：
解决办法：
1.进行多次count运算，然后相加（性能损耗太大，多少表多少次）
2.记录数表：每次insert delete 都修改记录数表的字段（不能和业务同一个事务，如果逻辑遗漏 数据就对不上了） 如果不要求实时，可以定时任务刷新
order by操作问题：
只能由业务代码 数据库中间件分别查询每个子表中的数据，然后汇总进行排序。
明天要做的事：mysql安装到我虚拟机上，数据导入，测试性能，然后搭建读写分离，搭建Java项目，准备测试性能
网友评论