关于数据库性能的故事
面试时多多少少会讲到数据库上的事情，“你对数据库的掌握如何？”，什么时候最考验数据库的性能，答应主要方面上讲就是大数据量的读写时，而电商类的大促活动就是考验各自的数据库性能的时候啦。
对于web服务器而言，数据量大时，我们可以简单的通过横向扩展来减少单个服务器的负担，但是对于数据库服务器来说就没有那么简单了，他们不可能做到轻易的横向扩展，这样也违背了数据库的完整性与一致性的原则，那么我们的数据库架构该如何搭建呢？
对于大促类活动而言，不管是产品多好、策划多成功，如果没有稳定的数据库及服务器环境，则这所谓的一切都将是一场空呀。
数据库架构案例
如图所示，主从服务器之间没有任何主从复制组件，即当主服务器出现了故障，很难进行主服务器的切换，这需要DBA在从服务器中选择数据最新的从服务器将其提升为主服务器并同步其他从服务器，这个过程的时间成本也是非常沉重的。
且过多的从服务器，当业务量大时对主服务器的网卡也是一定的挑战。
我们可以通过对集群的监控信息来了解是什么影响了数据库性能。
答应其实是肯定的，一般情况下主要是QPS与TPS、并发量（同一时间处理的请求的数量，避免和同时连接数混淆）、磁盘IO、读操作过于高
这里有个建议：最好不要在主库上数据备份，起码在大型活动前要取消这类计划、
影响数据库的因素
超高的QPS和TPS
风险：效率底下的SQL(QPS：每秒钟处理的查询量)
大量的并发和超高的CPU使用率
风险：大量的并发（数据库连接数被占满（max_connections默认100））
风险：超高的CPU使用率（因CPU资源耗尽而出现宕机）
磁盘IO
风险：磁盘IO性能突然下降（使用更快的磁盘设备）
风险：其他大量消耗磁盘性能的计划任务（调整计划任务）
网卡流量
风险：网卡IO被占满（1000Mb/8=100MB）
如何避免无法连接数据库的情况：
1、减少从服务器的数量
2、进行分级缓存
3、避免使用“select * ”进行查询
4、分离业务网络和服务器网络
