MYSQL性能管理及架构设计-1

用心分享每一篇干货
一
是什么决定了电商双11大促的成败？！

就按照市面上的上线电商平台而言，一个交互性优越的前端架构，一个或多个web服务器（可横向扩展）及数据库服务器。

那么问题来了，数据库服务器并不能和web服务器一样进行横向扩展，毕竟不是代码，不能随意的粘贴复制，那么我们就来聊聊双11中的大促中电商们的数据库架构。

一般均为一个主服务器、多个从服务器

Master——Slave×N

期间没有主从复用组件，一旦主服务器出现故障、不能立马切换

那么大促中什么影响了数据库性能呢？

sql查询速度、服务器硬件、网卡流量、磁盘IO

超高的QPS和TPS

风险：效率底下的SQL（mysql并不支持多cpu并发查询）

QPS：每秒钟处理的查询量

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

风险：大量的并发——数据库连接数被占满（max_connections默认100）

超高的CPU使用率——因CPU资源耗尽而出现宕机

磁盘IO

风险：磁盘IO性能突然下降（使用更快的磁盘设备）

其他大量消耗磁盘性能的计划任务（调整计划任务，做好磁盘维护）

网卡流量

风险：网卡IO被占满（1000Mb）

旅行 心率图分割线
如何避免无法连接数据库的情况：

1、减少从服务器的数量

2、进行分级缓存

3、避免使用“ SELECT * ”进行查询

4、分离业务网络和服务器网络

当然对于大型电商而言，还有大表给他们带来的各种问题

什么样的表可以称之为大表？这只是相对而言

·记录行数巨大，单表超过千万行

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

大表对查询的影响：

慢查询：很难再一定的时间内过滤出所需要的数据

显示订单——来源少——区分度低——大量磁盘IO——降低磁盘效率——大量慢查询

大表对DDL操作的影响：

建立索引需要很长时间

风险：MYSQL版本<5.5 建立索引会锁表

MYSQL版本>=5.5 虽然不会锁表但会引起主从延迟

修改表结构需要长时间锁表

风险：会造成长时间的主从延迟（主从复制为单线程）

影响正常的数据操作

如何处理数据库中的大表

1、分库分表把一张大表分成多个小表

难点：分表主键的选择、分表后跨分区数据的查询和统计

2、大表的历史数据归档

减少对前后端业务的影响

难点：归档时间点的选择、如何进行归档操作

除了大表 一定就还有大事务啦！

1、事务是数据库系统区别于其他一切文件系统的重要特性之一

2、事务是一组具有原子性的SQL语句，或是一个独立的工作单元

事务———原子性、一致性、隔离性、持久性

事务的原子性（ATOMICITY）

定义：一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败，对于一个事务来说，不可能只执行其中的一部分操作

（整个事务中的所有操作要么全部提交成功，要么全部失败回滚）

事务的一致性（CONSISTENCY）

定义：一致性是指事务将数据库从一种一致性状态转换到另一种一致性状态，在事务开始之前和事务结束后数据库中数据的完整性没有被破坏

事务的隔离性（ISOLATION）

定义：隔离性要求一个事务对数据库中数据的修改，在未提交完成之前对于其他事务是不可见的

SQL标准中定义的四种隔离级别

·未提交读（READ UNCOMMITED）

·已提交读（READ COMMITED）

·可重复读（REPEATABLE READ）

·可串行化（SERIALIZABLE）

（隔离性由低到高、并发性由高到低）

事务的持久性（DURABILITY）

定义：一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使西永崩溃，已经提交的修改数据也不会丢失

什么是大事务

定义：运行时间比较长，操作的数据比较多的事务

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

如何处理大事务

1、避免一次处理太多的数据

2、移除不必要在事务中的SELECT操作