mysql

在高并发、高访问、高交互时无论是web服务器还是数据库服务器都面临巨大的压力。

对于web服务器，我们可以横向扩展，只要有足够的服务器，我们可以部署项目到不同的服务器上。只要程序一样，则每台服务器对外部提供的内容都一致。

但对于数据库服务器就不能简单的横向扩展了。因为数据库的数据具有完整性和一致性，则数据库服务器的扩展就是最重要的。具体影响数据库性能的因素有哪些？

数据库架构

该架构中只有一个Master服务器也就是说只有一个主数据库服务器，也没有任何Master-Slave从复制的高可用组件，也就是说，一旦Master服务器出现了故障，很难自动的进行故障切换，我们必须主动的在Slave服务器中选择出数据最新的服务器手动切换为Master服务器，然后其他Slave服务器再进行数据同步。那么切换是比较耗时的。若当业务量大的时候，一边是高并发的请求，一边还在数据同步，对cpu的要求就更高，有可能出现问题。所以最好不要再主库上进行服务器数据备份，或者再大型活动期间不要暂时关闭这样的服务。

影响数据库性能的因素

1、慢查询（超高的QPS和TPS，大部分数据库性能80%都是由慢查询引起的）
风险：效率低下的sql，当访问量大量增长，超高的QPS和TPS数的产生，此时没处理一个Sql数的时间就特别重要。每个SQL只能使用一个CPU
QPS:每秒钟处理的查询量
TPS:
解决方案：SQL优化

2、大量的并发和CPU使用率
大量的并发：数据库连接数占满（max_connections=100默认值），有效的连接连不上
超高的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、修改表结构需要长时间锁表
风险：1、造成长时间的主从延迟（由于Mysql主从复制机制对于DDL操作都是先在主库上完成后，在通过日志传到从库上，再在从库上执行相同的操作，从而完成表结构变化复制。若一张表在主库上完成修改要500秒，那么在从服务器上至少也需要500秒完成修改，由于是单线程，所以一旦有大表的修改再从服务器上没有完成前，其他的修改操作都无法执行，连接数就会大量增加）
2、影响正常的数据操作

解决办法：
分库分表（难点：分表主键选择、分表后跨分区数据的查询和统计）
大表历史数据归档较少对前后端业务的影响（难点：归档时间点选择、如何归档
）

6、大事务：运行时间比较长，操作的数据比较多的事务