什么影响了数据库的性能？

老师曾经从业过的一家电商公司，

若是主服务器出现故障；

因为从服务器比较多，切换从服务器最少须要半个小时的时间；并且这种从服务器不少的架构，当访问量很大的时候，对服务器的网卡也是很大的挑战，容易引发故障；
咱们能够从监控信息来判断影响服务器 性能的缘由


磁盘IO用的是fashion IO

凌晨，读的峰值很大（可能说明服务器性能急剧降低），检查后，由于是数据库备份远程同步计划任务形成的。

并发量：同一时间处理的请求的数量
TPS - Transactions Per Second（每秒传输的事物处理个数），这是指服务器每秒处理的事务数，支持事务的存储引擎如InnoDB等特有的一个性能指标。
计算方法：
TPS = (COM_COMMIT + COM_ROLLBACK)/UPTIME

use information_schema;  
select VARIABLE_VALUE into @num_com from GLOBAL_STATUS where VARIABLE_NAME ='COM_COMMIT';  
select VARIABLE_VALUE into @num_roll from GLOBAL_STATUS where VARIABLE_NAME ='COM_ROLLBACK';  
select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME ='UPTIME';  
select (@num_com+@num_roll)/@uptime;

• 1
• 2
• 3
• 4
• 5

QPS - Queries Per Second（每秒查询处理量）同时适用与InnoDB和MyISAM 引擎
计算方法：
QPS=QUESTIONS/UPTIME

use information_schema;  
select VARIABLE_VALUE into @num_queries from GLOBAL_STATUS where VARIABLE_NAME ='QUESTIONS';  
select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME ='UPTIME';  
select @num_queries/@uptime;

• 1
• 2
• 3
• 4

详情：http://blog.csdn.net/wind19/article/details/8600083

mysql目前并不支持多CPU，只支持单CPU；

大促来袭，访问量急速增长，对于超高的QPS和TPS,效率低下的sql是很大的风险，
大部分数据库问题都是因为慢查询形成的，也就是说能够优化sql来解决问题；

这里的并发是链接数；
发生在热数据远远大于服务器可用内存的状况下

主备份迁移到从备份，磁盘报警及时处理





comment：备注，这个数据表记录上亿

来源只有四个，要从上亿找一小部分数据，将产生大量的磁盘IO;

单线程的问题

好比频繁更新的订单日志表，若是在更新时修改表结构，会致使数据链接数忽然猛增，链接数被沾满，500错误，boss顶你个肺；
解决思路：传说中的分库分表


大事务带来的问题


失败，所有操做回滚；

已提交读（不重复读）和重复读的区别是
重复读（一个用户在其事务没有结束时不能够获得另外一个用户已经执行完的事务的结果），可是已提交读是能够的。
（隔离性最高，并发性最低）串行化会在读取的每一行上多加锁，因此可能会出现比较多的锁超时事件
事务的持久性（DURABILITY）

查看事务的结构
show variables like '%iso%';
更改事务结构
set session tx_isolation='事务类型';

• 1
• 2
• 3
• 4