在高并发、高访问、高交互时无论是web服务器还是数据库服务器都面临巨大的压力。
对于web服务器，我们可以横向扩展，只要有足够的服务器，我们可以部署项目到不同的服务器上。只要程序一样，则每台服务器对外部提供的内容都一致。
但对于数据库服务器就不能简单的横向扩展了。因为数据库的数据具有完整性和一致性，则数据库服务器的扩展就是最重要的。具体影响数据库性能的因素有哪些？
数据库架构
大多数公司项目数据库架构以下架构，一个主服务器，多个从服务器
该架构中只有一个Master服务器也就是说只有一个主数据库服务器，也没有任何Master-Slave从复制的高可用组件，也就是说，一旦Master服务器出现了故障，很难自动的进行故障切换，我们必须主动的在Slave服务器中选择出数据最新的服务器手动切换为Master服务器，然后其他Slave服务器再进行数据同步。那么切换是比较耗时的。若当业务量大的时候，一边是高并发的请求，一边还在数据同步，对cpu的要求就更高，有可能出现问题。所以最好不要再主库上进行服务器数据备份，或者再大型活动期间不要暂时关闭这样的服务。
QPS&TPS
并发量（同一时间处理的请求数量）&CPU使用率
同时连接数>请求数（同一时间一些连接处于sleep状态）
影响数据库性能的因素
1、sql查询速度(数据库性能80%都是由慢查询引起的)
风险：效率低下的sql，当访问量大量增长，超高的QPS和TPS数的产生，此时没处理一个Sql数的时间就特别重要。每个SQL只能使用一个CPU
QPS：每秒钟处理的查询量。
10ms处理1个SQL，1s处理100个SQL 则QPS<=100,那么QPS将近于100（CPU还有其他地方占用）若100ms处理1个SQL，则QPS<=10
解决方案：SQL优化
2、大量的并发和CPU使用率
风险：大量的并发：数据库连接数占满，有效的连接连不上，出现500。超高的CPU使用率：因CPU资源耗尽而出现的宕机
3、磁盘IO（数据库服务器的主要瓶颈之一)
风险：磁盘IO性能突然下降
解决办法
1、使用更快的磁盘设备，SSD卡、Read卡、fationIo
2、调整其他其他消耗磁盘性能的计划任务（如平时在主库上备份，大促时则调整到从库备份）
4、网卡流量
风险：网卡IO被占满（1000Mb/8~100MB）若大促时网卡流量被跑满，则再有新链接查询数据库，则无法连接数据库，从而影响正常业务访问
解决办法
1、减少Slave服务器的数量slave服务器会从主服务器上复制日志，所以Slave服务器越多，网络流量越大。
2、进行分级缓存，尽量避免前端大量的缓存突然失效，对数据库流量的冲击
3、避免使用select * 这样的查询，避免查询不必要的字段
4、分离业务网络和服务器网络
5、大表
记录行数巨大，表单超过千万行
表数据文件巨大，表数据文件超过10G
注意：要和业务场景相结合，若该表只是用来记录日志的，只有insert操作和少量的select操作几乎没有update和delete操作，这样的表超过1000万行，则对我们的业务也不会有太大的影响。但如果有一天，业务发生变更，需要加入更多的列的时候，就是一件痛苦的事情了。
大表产生的问题：大表往往意味着慢查询的产生。大表对DDL操作影响:1、建立索引需要很长的时间、2、修改表结构需要长时间锁表。（由于Mysql主从复制机制对于DDL操作都是先在主库上完成后，在通过日志传到从库上，再在从库上执行相同的操作，从而完成表结构变化复制。若一张表在主库上完成修改要500秒，那么在从服务器上至少也需要500秒完成修改，所以一旦有大表的修改再从服务器上没有完成前，其他的修改操作都无法执行，连接数就会大量增加）
解决办法：
分库分表（分表主键选择、分表后跨分区数据的查询和统计）
大表历史数据归档（订单表、日志表等）难点：归档时间点选择、如何归档。
