超高的QPS和TPS

QPS(Query Per Second)
风险：效率低下的SQL。数据库中的性能问题80%就是由慢查询造成的。也就是大多数的数据库问题可以通过对SQL进行优化来解决。

TPS（Transition Per Second）

大量并发和超过的CPU使用率

高并发可能导致DB连接被占满；超高CPU使用率可能因为CPU资源耗尽而出现宕机。这里并发量指的是同一时刻需要DB服务器处理请求的数量，而连接量往往比并发量大得多，因为现在的系统中每一个前端服务器（例如nginx,tomcat,apache）都会对数据库建立多个连接，而在众多的连接中往往只有几个是在请求数据库处理的，其他的大多数连接都会处于sleep状态。数据库对于允许建立的连接数目是有限的（max_connections默认为100）

磁盘IO

磁盘IO性能突然下降（使用更快的磁盘设备，SSD，fashion IO），其他大量消耗磁盘性能的计划任务（调整计划任务，做好磁盘维护）。例如平时在主库上进行备份的，在大促的时候应该切换到从库上备份。

网卡流量

大多数网卡是1000mbps (bits) = 1000 / 8 = 100 MB/s(byte)

如何避免无法连接数据库的情况：

1. 减少从服务器的数量。（从服务器需要从主服务器上进行复制）
2. 进行分级缓存
3. 避免使用SELECT *
4. 分离业务网络和服务器网络

大表带来的问题

大表可以从2个维度来进行定义：

• 记录数目巨大，单表超过1000W行
• 表数据文件巨大，超过10G
• 大表往往意味着慢查询（很难在一定时间内过滤出所需要的数据）的产生，大表往往会降低SQL的效率。
• 大表对DDL也会产生影响。例如建立索引需要很长时间。5.5版本以下建立索引会锁表，而>=5.5的时候虽然不会锁表，但是会引起主从延迟。

对于大表有2种策略：分库分表和历史数据归档

分库分表把大表分成多个小表

难点：

• 分表主键的选择
• 分表后跨分区数据的查询和统计

大表的历史数据归档，可以尽量减少业务前后端的影响。难点在于：

• 归档时间点的选择
• 如何进行归档操作

大事务带来的问题

事务的隔离性（ISOLATION），SQL标准中定义了4种隔离级别：

SHOW VARIABLES LIKE '%iso%';
SQL
Copy

• 未提交读（READ UNCOMMITED）
• 已提交读 (READ COMMITED)
• 可重复读 (REPEATABLE READ)，InnoDB默认级别。
• 可串行化（SERIALIZABLE）,最高

验证事务的隔离级别我们可以分别连接到两个mysql shell，在一个shell中进行插入操作

大事务的运行时间比较长，操作的数据比较多的事务。可能造成锁定太多数据，造成大量的阻塞和锁超时。回滚的时间较长，并且在回滚的过程中数据也是被锁定的。执行时间长可能造成主从延迟。

处理大事务一般有以下的策略：

1. 避免一次性处理太多数据，可以进行分批处理；
2. 查询操作（SELECT）可以从事务中移除，事务中只保留必要的写操作。