mysql数据库架构及性能分析

版权声明:个人博客网址 https://29dch.github.io/ 博主GitHub网址 https://github.com/29DCH,欢迎大家前来交流探讨和fork! https://blog.csdn.net/CowBoySoBusy/article/details/82847013

一般架构为主从数据库服务器搭配,例如一台Master(主服务器)对应着十几台或者上百台Slave(从服务器),如果没有高可用的主从复制组件的话,当主服务器遇到意外情况崩溃时,很难自动进行故障切换,必须由DBA手动从众多从服务器中选择数据最新的提升为主服务器,其他从服务器再对这个新主服务器进行同步,这个过程又耗时间有占用大量主服务器的网卡容量.
  数据库服务器的性能指标:QPS & TPS,并发量,CPU使用率
  并发量:同一时间处理请求的数量,注意和同时连接数(一般比数据库并发量大得多,因为有的数据库连接处于sleep状态,不发出请求)区分开来
  磁盘IO:fashion IO,吞吐量比普通磁盘大很多,注意:最好不要在主库上数据库备份,在大型活动前取消此类操作,会损耗服务器性能
  影响数据库的因素:
  1.sql查询速度
  2.服务器硬件
  3.网卡流量
  4.磁盘IO
 详细情况如下:
超高的QPS和TPS的风险是导致效率低下的SQL(当前mysql不支持多cpu并发运算)
附:
在mysql中
TPS -(Transactions Per Second) :数据库的每秒传输的事物处理个数,主要是对事务性存储引擎(InnoDB)的一个性能指标。
计算方法:TPS = (COM_COMMIT + COM_ROLLBACK)/UPTIME
SQL语句: USE information_schema; SELECT VARIABLE_VALUE INTO @com_commit FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘COM_COMMIT’; SELECT VARIABLE_VALUE INTO @com_rollback FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘COM_ROLLBACK’; SELECT VARIABLE_VALUE INTO @uptime FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘UPTIME’; SELECT (@com_commit+@com_rollback)/@uptime;

QPS -(Queries Per Second) :数据库的每秒查询处理量,同时适用InnoDB和MyISAM 等存储引擎。
计算方法:QPS=QUESTIONS/UPTIME
sql语句:USE information_schema; SELECT VARIABLE_VALUE INTO @questions FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘QUESTIONS’; SELECT VARIABLE_VALUE INTO @uptime FROM GLOBAL_STATUS WHERE VARIABLE_NAME =‘UPTIME’; SELECT @questions/@uptime;
可见sql优化是十分重要的

大量的并发和超高的CPU使用率
风险:
大量的并发导致数据库连接数被占满(max_connections默认为100)
超高的CPU使用率导致因CPU资源的耗尽出现宕机情况

如果磁盘IO性能突然下降,后期只能使用更快的磁盘设备

网卡流量:网卡IO被占满,可以通过减少从服务器的数量,进行分级缓存,避免使用"select *"此类查询
,分离业务网络和服务器网络(避免数据库备份影响性能)来解决

大表的影响:
大表的定义(相对):记录行数巨大,单表超过千万行;表数据文件巨大,超过10G
影响:查询慢;对DDL来说,建立索引需要很长时间,引起锁表或者主从延迟
解决办法:分库分表(难点:分表主键的选择;分表后跨分区数据的查询和统计);大表的历史数据归档(可以减少对前后端业务的影响,难点是归档时间点的选择和如何进行归档操作)

大事务的影响:
事务:是一组具有原子性的SQL语句,或是一个独立的工作单元;特点:ACID
原子性(atomicity):要么全部提交成功,要么全部不执行或者失败回滚,不能只执行一部分.
一致性(consistency):将数据库从一种一致性状态转换到另一种一致性状态,在事务开始之前和事务结束之后数据库中的数据完整性没有被破坏.
隔离性(isolation):一个事务对数据库中的数据的修改,在未提交完成前对于其他事务是不可见的.
在这里插入图片描述
持久性(durability):一旦事务提交,其所做的修改将永久保存到数据库中,此时即使系统崩溃,提交的修改数据也不会丢失.
大事务:运行时间比较长,操作数据比较多的事务
风险:锁定太多的数据,造成大量的阻塞和锁超时;回滚所需时间比较长;执行时间长,容易造成主从延迟.
如何处理大事务:
1.避免一次处理太多数据
2.移除不必要在事务中的select操作

影响数据库性能的因素:
服务器硬件;服务器系统;数据库存储引擎的选择;数据库参数配置(影响很大);数据库(表)结构设计和SQL语句(慢查询是最大原因)
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/CowBoySoBusy/article/details/82847013
今日推荐