打造扛得住的MYSQL数据库架构

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

如果主服务器出现故障；

由于从服务器比较多，切换从服务器最少需要半个小时的时间；而且这种从服务器很多的架构，当访问量很大的时候，对服务器的网卡也是很大的挑战，容易引起故障；
我们可以从监控信息来判断影响服务器 性能的原因


磁盘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;  

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; 

详情：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='事务类型';