mysql优化 博客园_MySQL优化

A数据库可以优化层面

1数据库结构的优化(硬件升级,读写分离,分表技术,,添加缓存数据库)

2表结构的优化(3范式设计,反三范式的设计,使用合适的存储引擎)

3语句的优化(使用存储过程和触发器,合理使用索引)

B优化的思路:

1183affbec20a490ef0519b280bf06f6.png

17b580a260f0587b5ca3f39437581792.png

如果是周期性波动,则需要调整缓存的缓存清除策略,防止内存穿透,击穿和雪崩

如果不是周期性的问题,则需要通过processlist去分析是语句等待的时间问题还是语句的执行问题

语句的等待时间问题,则需调整数据库服务器的缓冲区和线程数

如果是语句问题,可以使用show profile for query,和explain去分析语句的具体执行细节。

数据库结构的优化:

。。。。。。。。。。。。。。。

2表结构的优化

表的设计,首先需要按照三范式去设计

确保每列的原子性(约束表的所有字段)(规范话所有字段,都不可再分如(中国广东,必须要分开))

非键字段必须依赖于键字段(一个表只描述一件事(如老师表,不存放学生表的信息))(主键时表的关键字段,非主键是具体描述这个表的信息)

消除传递依赖(非主键字段中,如果一个字段可以推导出另外一个字段,这叫传递依赖)

在次基础上,为了提高查询效率,可以适当增加表冗余,以减低表查询时,在关联表的时候,耗费的时间(具体需要结合业务场景)

存储引擎的选择:

innodb

mymisan

Myisam不支持事务,查询效率高,碎片化多

(使用了)

1字段类型的选择优先级:

整型>date,time>enum,char,varchar>blob

2.字段的空间够用即可,不要设置过大

3.尽量不用null,用其他值代替,因为null不利于索引,要用特殊字符标识,占更大的空间

Myisam的次索引和主索引 都指向物理行(根据数的节点信息,使用指针到物理地址找出信息)

89cf30d64bebfdaf271bc753ca398797.png

Innodb.支持视物,数据的修改优

innodb的次索引指向对主键的引用(主索引的叶子节点已存在具体的行信息)

3语句的优化

存储过程和触发器。是已经在数据库服务器编译好的语句,直接执行返回结果即可,节省了传输语句和编译语句耗费的时间

361ed8661e1d5205f8af8ce46d358c55.png

建立索引。

主键索引与唯一索引的区别

主键:只能有一个,不能重复,不能为空

唯一:可以有多个,不能重复,可以为空

独立索引只能使用一个,为了提高效率,可以使用联合索引

a1b11c69d52a89748ee75e723668ccd9.png

3b6471207929bfc66ca95b8ec65e2aed.png

因为排了c3再排c2,c2需要sql服务器去重新排序,所以extra出现;了filesort

extra的参数含义:

9c93712ac8235504cabb8d960fe50820.png

建索引需要注意的内容:

理想的索引:

1.查询频繁

2.区分度高(可以通过这条语句去去确定)

fd88b82ce6bd9781f2182c561597d556.png

索引只截取的字段的前几个字符

15cab2cef95543bb8152344746d845dc.png

看扫描的行数可以判断查询效率

0ecf75f941972a8204c5e634df1dd3f4.png

值越接近1,区分度越高,一般到达0.9已经是可接收的程度了

用crc函数,将字符转为hash列,降低索引长度,提高查询效率

df376dd96f9b0eab9f19317e5fd598df.png

延迟关联:

87d960a4d6e9e48972571fad5f64baee.png

先使用id查询,实现索引覆盖,再使用关联擦查询,查询limit后的内容

延迟查询是先再节点中找到位置,再到物理地址获取

3b153c0ddfb16c41fa7e7f8f2dff2d07.png

e50cd05c4834695f8b521d0021e30f67.png

Explian的字段解释select——type(simple不含子查询)

Table 表名

fc4ac74b521558abc92cb4363ed8f52a.png

Type列:

3eab59c28b81c535c9674027a68f11bc.png

7033bb4c828585c204aa8f7917afea20.png

3f965bc316bf7eab21ede728e9facbc7.png

6ac44304d71d2f6bec999dcc5d9e429e.png

Ref,索引迅速定位到某一个范围

2ef767876f74847c26765888d42b4f4f.png

3325b69645b69d69ed3b3826e93299ec.png

In子查询,先查主表再查次表,

Exit和关联查询的主次表查询顺序

要用分析器explian去分析 (尽量让少的表去全盘扫面,不要生产临时表)

数据库的优化,需要从服务器,表的设计,索引去优化,到语句的优化层,可优化的空间已经很小了

3.长度小

4.尽量能覆盖常用的查询字段

如果是innodb,

有多个比较长的列

是聚族索引,导致沿id排序时,要跨好多小文件

有比较长的列,导入块比较多

如果使用复合索引的时候,只会去主键索引中查找,不存在主键索引的跨快问题(符合索引类似于指针)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值