学习小d课堂 新版ShardingJDBC分库分表mysql数据库实战 笔记
【Sharding-JDBC-1】Mysql架构演变升级+分库分表优缺点
数据库的演变升级
-
单机
- 请求量大查询慢
- 单机故障导致业务不可用
-
主从
- 数据库主从同步，从库可以水平扩展，满足更大读需求
- 但单服务器TPS，内存，IO都是有限的
- 可以考虑用主节点负责业务，从节点负责统计
-
双主
- 用户量级上来后，写请求越来越多
- 一个Master是不能解决问题的，添加多了个主节点进行写入，
- 多个主节点数据要保存一致性，写操作需要2个master之间同步更加复杂
-
分库和分表
自研工具类、tddl、shardingsphere、mycat等
【面试题】业务增长-数据库性能优化
这边有个数据库-单表1千万数据，未来1年还会增长多500万，性能比较慢，说下你的优化思路
- 思路
- 千万不要一上来就说分库分表，这个是最忌讳的事项
- 一定要根据实际情况分析，两个角度思考
- 不分库分表
- 软优化
- 数据库参数调优
- 分析慢查询SQL语句，分析执行计划，进行sql改写和程序改写
- 优化数据库索引结构
- 优化数据表结构优化
- 引入NOSQL和程序架构调整
- 硬优化
- 提升系统硬件（为了更快的IO、更多的内存）：带宽、CPU、硬盘
- 软优化
- 分库分表
- 根据业务情况而定，选择合适的分库分表策略（没有通用的策略）
- 外卖、物流、电商领域
- 先看只分表是否满足业务的需求和未来增长
- 数据库分表能够解决单表数据量很大的时,数据查询的效率问题，
- 无法给数据库的并发操作带来效率上的提高，分表的实质还是在一个数据库上进行的操作，受数据库IO性能的限制
- 如果单分表满足不了需求，再分库分表一起
- 根据业务情况而定，选择合适的分库分表策略（没有通用的策略）
- 不分库分表
- 结论
- 在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案
- 如果数据量极大，且业务持续增长快，再考虑分库分表方案
Mysql数据库分库分表后带来的优点
分库分表解决的现状问题
可以解决数据库本身的瓶颈以及系统本身的瓶颈
- 解决数据库本身瓶颈
- 连接数： 连接数过多时，就会出现‘too many connections’的错误，访问量太大或者数据库设置的最大连接数太小的原因
- Mysql默认的最大连接数为100可以修改，而mysql服务允许的最大连接数为16384
数据库分表可以解决单表海量数据的查询性能问题
数据库分库可以解决单台数据库的并发访问压力问题
- 解决系统本身IO、CPU瓶颈
- 磁盘读写IO瓶颈，热点数据太多，尽管使用了数据库本身缓存，但是依旧有大量IO,导致sql执行速度慢
- 网络IO瓶颈，请求的数据太多，数据传输大，网络带宽不够，链路响应时间变长
- CPU瓶颈，尤其在基础数据量大单机复杂SQL计算，SQL语句执行占用CPU使用率高，也有扫描行数大、锁冲突、锁等待等原因
- 可以通过 show processlist; 、show full processlist，发现 CPU 使用率比较高的SQL
- 常见的对于查询时间长，State 列值是 Sending data，Copying to tmp table，Copying to tmp table on disk，Sorting result，Using filesort 等都是可能有性能问题SQL，清楚相关影响问题的情况可以kill掉
- 也存在执行时间短，但是CPU占用率高的SQL，通过上面命令查询不到，这个时候最好通过执行计划分析explain进行分析
修订记录
2022-02-07 18:14:41