数据库优化

Mysql 的索引’

概述：索引就是编号，添加索引后，查询效率会提升，增删改效率会相对下降

分类：普通索引

惟一索引：咱们之前用的主键约束，惟一约束就是俩个比较特殊的惟一索引

建立普通索引

create index 索引名 on 数据表名（字段名（长度））；

建立惟一索引：

create unique index 索引名 on 数据表名（字段名（长度））

删除索引 ：alter table 数据表名 drop index 索引名 //删除普通索引

alter table 数据表名 drop primary key; //删除主键索引

显示索引信息

show index from 数据表名

事务的概述:

事务指的是逻辑上的一组操做,组成该操做的各个逻辑单元,要么所有成功,要么所有失败

事务的特色:ACID

原子性 :事务的各个逻辑单元已经是最小单位,不可继续分割

一致性:事务执行先后的数据应该保持一致

隔离性: 一个事务执行的过程当中不受其余事务的干扰

持久性:事务执行完以后 结果应持久化到数据表中,进行永久存储

效率从高到低分别是:

read unconmmitted>read committed >repeatable read >serializable

隔离级别:

serializable >repeatable read > read committed > read uncommitted

事务控制语句:

begin 或者 start transaction   //开启事务

commit  //提交事务

rollback // 回滚事务

sql 操做事务的流程

1. 开启事务

begin 或者 start transaction

1. 执行相关操做

例如

先执行 50% -->保存一个节点(savepoint)

再接着执行 25% -->保存一个节点

最后在执行25%的时候,发现前25%执行错误, 若是采用rollback回滚事务会致使效率下降 ,能够经过恢复节点的方式进行处理将数据恢复到执行完50%节点上,而后执行剩下的俩个25%

3)提交事务,若是整条SQL语句执行都有问题,能够选择回滚事务

mysql 使用事务时可能遇到的问题

1)多个事务并发执行,会致使(脏读, 不可重复读,  虚读)

2)事务在运行过程当中被强行中止

不考虑隔离性的问题和解决方案

脏读:  读未提交  一个事务读取到另外一个事务还没来得及提交的数据

不 可重复读: 读已提交  一个事务读取到另外一个事务已经提交的修改数据 致使俩次查询结果不一致

虚读 :一个事务读取到了另外一个事务已经提交的添加的数据 致使俩次查询结果不一致

串行化读取:

一个事务A在操做某一张表的时候,另外一个事务必须等待A操做完毕后草能够操做该表

四大隔离性:

read uncommitted :读未提交 可能发生脏读 不可重复读 ,虚读

read committed : 读已提交 能规避脏读, 可能发生不可重复读 虚读

repeatable read : 可重复读 能规避 脏读 不可重复读 可能发生虚读

serializable  能规避脏读, 不可重复读 虚读

mysql 的封锁

排它锁 //x锁 :可读可写 一个事务对表加了X锁 其它事务必须等到该事务操做完这张表后,才能够対这张表操做

共享锁 ://S 锁  只读 多个事务能够同时对么一张表加共享锁

活锁 // 有概率解开  某个事务在永远等待的状态,得不到封锁的机会 这种现象称为活锁

死锁 :确定解不开  俩个或俩个以上的事务都处于等待状态每一个事务都在等待对方事务接触封锁 这样任何事务都处于等待状态而没法继续执行的现象称为死锁

mysql的目录结构

/etc/my.cnf       //这是mysql的主配置文件  Linux 操做系统中后缀名是.cnf window 系统中是.ini

/var/lib/mysql    //mysql中数据库及数据存储的目录

/var/log/mysql   //数据库的日志文件存放目录   该路径也多是/var/lib/mysql

netstat  -nltp  //查看端口

//ps -ef | grep mysql  //查看全部课mysql 相关的进程

数据库分类

关系型数据库 : mysql  Oracle  sqlserver

非关系型数据库 :redis hbase 等

数据库设计流程:

1. 需求分析: 明确客户需求 到底作什么?

2. 概念模型设计 : 该阶段是整个数据库设计的关键 它经过对用户需求进行综合,概括 与抽象 主要是经过E-R图表示

优势 :简洁明了 描述了各个表之间的逻辑关系 独立于计算机与具体的RDBMS无关

3)逻辑模型设计 :与具体的数据库相关,反应业务部门的

4)数据库实施: 建立数据库 定义数据库结构 组织数据入库 调试数据库并进行数据库的试运行

5)数据库的运行和维护 :数据库正式运行以后对数据库运行过程当中对其进行评价 调整 修改 调优等

数据库设计遵循的原则

范式 就是符合某一规范级别的关系模式的集合 共有7种范式

第一范式 :每一个属性都是不可分割的

第二范式: 主属性(主键)和 非主属性 直接依赖

第三范式 : 主属性(主键) 和非主属性 间接依赖

优势

1)范式主要说明的就是:设计表的时候,扩展拆分(分离)程度

1. 范式越高,会让扩展的程度变得更好

缺点:编写sql 语句时会变得更加的繁琐

为何要进行数据库的优化

1)避免网站页面出现访问错误

因为数据库链接超时产生页面错误,因为慢查询形成页面没法加载

2)增长数据库的稳定性

很对数据库问题都是因为低效的查询引发的

3)优化用户体验

    流畅页面的访问速度

     良好的功能体验

数据库优化的方案

优化"成本"从低到高分别为 :

Sql 语句及索引 --> 数据表结构--> 系统配置-->硬件

1)sql 及索引优化

  根据需求写出良好的sql 并建立有效的索引 ,实现一种需求可有多种写法 这时候咱们就须要选择一种效率高的写法 这个时候就须要Sql 优化

2)数据库表结构优化 

根据数据库的范式,设计表结构 ,表结构设计的好坏直接关系到写SQL语句

3)系统配置的优化

     大多数运行在Linux机器上 ,如tcp 链接数的限制, 打开文件数的限制,安全性的限制,所以咱们要对这些配置进行相应的优化

 4)硬件配置优化

选择合适数据库服务的cpu 更快的io   更高的内存 

如何发现有问题的sql

mysql 提供了慢查询日志查看功能,能够帮助查看某一条sql语句执行的一些状态

查看mysql 是否开启慢查询日志

show variables like '%slow %'  //默认是关闭状态

启用mysql 的慢查询日志功能

set global log queries not using_indexes=on // 将不使用索引的慢查询日志进行记录

set global slow_query_log=on // 开启慢查询日志

show variables like '%slow%'// 查看慢查询日志存储的位置

set global long_query_time=1 //大于1秒钟的数据记录到慢日志中 若是设置为默认0 则会有大量的信息存贮在磁盘中,磁盘很容易满掉

监听日志文件,看是否写入 若是本身不当心删除了 log 日志文件 重启下mysql 服务 而后从新登陆便可 service mysql restart

如何经过慢查询日志发现有问题的sql

a)查询次数多且每次查询占用时间长的sql

b) Io大的sql :扫描的行数越多,IO 越大

c) 未命中索引的sql

explain 关键字: 

sql 的执行计划 侧面反映出了sql的执行效率  具体的执行方式是只须要在执行的sql前面加上explain 关键字便可

用法 : explain select *from film ; // 查看指定 sql的执行效率 (横向排列)

explain  select * from film \g  // 查看指定的sql 的执行效率 (纵向排列)

名词解释:

table :显示这一行的数据是关于哪张表的

type : 这是重要的列,显示链接使用了何种类型 链接类型从最好到最差分别为

const >eq_reg >ref >range >index 和all  

possible_keys 显示可能应用在这张表中的索引

key:实际使用的索引,若是为null则没使用索引

key_len 使用索引的长度 ,在不损失精确性的状况下,长度越短越好

ref:显示索引的那一列被使用了

rows: mysql 认为必须检查的用来返回请求数据的行数

总结: 咱们重点关注的是type(尽量不要查询整张表) key (尽量使用索引).rows_(行数不能太大,尽量下降扫描次数)

聚合函数的优化方案 : 经过加索引的方式实现优化  而后执行查询语句 索引是顺序操做的 不须要扫描表,执行效率就会比较恒定

子查询的优化

子查询 是咱们在开发过程当中常用的一种方式,在一般状况下 须要把子查询优化为join查询 但在优化时 须要注意是否有一对多的关系 要注意重复数据  注: 在编写代码的时候,若是使用子查询可能会比多表链接查询更加的简单 因此在开发阶段可使用子查询 只要能知足须要就能够但在正式上线商业化使用的时候,尽量将子查询更改成join查询会更好一点 join查询的效率要比子查询的效率更高  建议:能够先用子查询实现功能,而后后期再优化为链接查询便可

group by 分组优化 :先分组

limit 查询的优化

select film_id,description from where film_id>=150 and film_id<155  oder by film_id limit 150 ,5; 扫描行数不变, 执行计划很 固定,效率也是很固定的 

注意 :主键要顺序排序并连续的 若是主键中缺了某一列 或者某 几列 会出现数据不足5行的数据 若是不连续,创建一个附加的index_id 列 保证这一列数据要自增的,并添加索引便可

总结: 尽量避免文件排序 和row的扫描(越少越好)由于这俩种操做都会增长IO的操做 从而下降sql语句的效率.