保障完整性和一致性
数据库架构
master(1)—slave(15)
没有主从复制组件
当Master发生鼓掌时,DBA手动选择一个新的服务器
缺陷:耗时较多
监控
fashion IO 吞吐量比普通磁盘大很多
影响数据库的因素
超高的QPS和TPS
风险:效率低下的SQL
QPS:每秒钟处理的查询量
大量的并发和超高的CPU使用率
风险:大量的并发导致数据库连接数被占满(max_connection默认为100)
超高的CPU使用率因CPU资源耗尽而出现宕机
磁盘IO
风险:磁盘IO性能突然下降
使用更快的磁盘设备
其它大量消耗磁盘性能的计划任务(调整计划任务,做好磁盘维护)
网卡流量
风险:网卡IO被占满
如何避免无法连接数据库的情况
记录行数巨大,单表超过千万行
表数据文件巨大,表数据文件超过10G
大表对查询的影响—慢查询:很难在一定的时间内过滤出所需要的数据
CREATE TABLE `buy_logs`(
`id` int(11) not null auto_increment comment '自增id',
`uid` int(11) not null comment '下单用户id',
`order_from` varchar(5) not null comment '订单来源:web,jd,tb,qq',
`order_id` int(11) not null comment '订单id',
`create_time` datatime not null comment '下单时间',
primary key(`id`)
)ENGINE=MYISAM DEFAULT CHARSET=utf8;
订单数据达到了亿条,订单来源少,区分度低,查询一部分数据会产生大量的磁盘IO,降低磁盘效率
大促时销售量的排行,会搞掉数据库
大表对DDL操作的影响
建立索引需要很长的时间
MySQL版本<5.5 建立索引会锁表
MySQL版本>=5.5 虽然不会锁表但会引起主从延迟
修改表结构需要长时间锁表
风险:会造成长时间的主从延迟
影响正常的数据操作,造成数据库连接数被占满
分库分表把一张大表分成多个小表
难点
大表的历史数据归档
减少对前后端业务的影响
难点
事务是数据库系统区别于其它一切文件系统的重要特性之一
事务是一组具有原子性的SQL语句,或是一个独立的工作单元
事务特性
原子性ATOMICITY
一个事务必须被视为一个不可分割的最小工作单元,整个事务中的所有操作要么全部提交成功,要么全部提交失败,对于一个事务来说,不可能只执行其中的一部分操作
eg:银行
一致性CONSISTENCY
一致性是指事务将数据库从一种一致性状态转换到另外一种一致性状态,在事务开始之前和事务结束后数据库中数据的完整性没有被破坏
隔离性ISOLATION
要求一个事务对数据库中数据的修改,在未提交完成前对于其它事务是不可见的
SQL标准四种隔离级别
并发性由高到低(1~4)
--查询数据库隔离级别
show variables like '%iso%';
--设定已提交读
set session tx_isolation='read-committed';
持久性DURABILITY
一旦事务提交,则其所做的修改就会永久保存到数据库中.此时即使系统崩溃,已经提交的修改数据也不会丢失
大事务
定义:运行时间比较长,操作的数据比较多的事务
风险:
处理: