Mysql数据库问题探讨

影响mysql数据库的主要方面：

1. sql查询速度
2. 服务器硬件
3. 网卡流量
4. 磁盘io

1.超高的QPS和TPS
QPS：每秒钟处理的查询量(每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准);

附上一个高峰时候的QPS的计算公式:
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。
每天300w PV 的在单台机器上，这台机器需要多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。
一般需要达到139QPS，因为是峰值。

2.大量的并发和超高的CPU使用率

并发用户:系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。
风险:
大量的并发：数据库连接数被占满(MYSQL中:max_connection默认100)，超过数量会造成无法连接数据库，从而500的错误。
超高的cpu使用率：因CPU资源耗尽而出现宕机

3.磁盘io
风险：
磁盘io性能突然下降(使用更快的磁盘设备)；在使用数据库峰值的时候，尽量不要在主库进行操作,要在从库进行
其他大量消耗磁盘性能的任务计划(调整计划任务,做好磁盘维护)

4.网卡流量
风险:网卡io占满，无法连接数据库的情况
1.减少从服务器的数量
2.进行分级缓存
3.避免使用'select *'进行查新
4.分离业务网络和服务器网络

5.大表带来的问题

定义:记录行数巨大，单表超过千万行

表数据文件巨大，表数据文件超过10G

对ddl的影响：

建立索引会花很长时间

风险：会造成长时间的主从延迟

影响正常的数据库操作

结决:

分库分表把一张大表分成多个小表（难点：分表后的主键选择,减少对前后端业务的影响）

大表的历史数据归档，减少对前后端业务的影响(难点:归档时间点选择，如何进行归档)

6.大事务带来的影响

慢查询：很难再一定时间内过滤出所需要的数据(定义：运行的时间比较长，操作的数据比较多的数据）

风险：所定义太多的数据时，造成大量的阻塞和锁超时,回滚所需要的时间比较长,执行时间比较长，容易造成主从延迟

处理

避免一次处理太多数据

移除不必要在事务中的select操作

最后附上事务的理解:

1、DEFAULT
默认隔离级别，每种数据库支持的事务隔离级别不一样，如果Spring配置事务时将isolation设置为这个值的话，那么将使用底层数据库的默认事务隔离级别。顺便说一句，如果使用的MySQL，可以使用"select @@tx_isolation"来查看默认的事务隔离级别
2、READ_UNCOMMITTED
读未提交，即能够读取到没有被提交的数据，所以很明显这个级别的隔离机制无法解决脏读、不可重复读、幻读中的任何一种，因此很少使用
3、READ_COMMITED
读已提交，即能够读到那些已经提交的数据，自然能够防止脏读，但是无法限制不可重复读和幻读
4、REPEATABLE_READ
重复读取，即在数据读出来之后加锁，类似"select * from XXX for update"，明确数据读取出来就是为了更新用的，所以要加一把锁，防止别人修改它。REPEATABLE_READ的意思也类似，读取了一条数据，这个事务不结束，别的事务就不可以改这条记录，这样就解决了脏读、不可重复读的问题，但是幻读的问题还是无法解决
5、SERLALIZABLE
串行化，最高的事务隔离级别，不管多少事务，挨个运行完一个事务的所有子事务之后才可以执行另外一个事务里面的所有子事务，这样就解决了脏读、不可重复读和幻读的问题了
网上专门有图用表格的形式列出了事务隔离级别解决的并发问题：

事务的隔离级别可以在mysql操作下用:

show variables like '%iso%';或者select @@global.tx_isolation;

设置当前事务隔离级别:

SET session TRANSACTION ISOLATION LEVEL Serializable;（参数可以为：Read uncommitted|Read committed|Repeatable read|Serializable）

设置全局事务隔离级别:

SET global TRANSACTION ISOLATION LEVEL Serializable;（参数可以为：Read uncommitted|Read committed|Repeatable read|Serializable）