MYSQL实战-------丁奇(极客时间)学习笔记

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: MYSQL实战-------丁奇(极客时间)学习笔记

MYSQL实战-------丁奇(极客时间)学习笔记

1.基础架构:一条sql查询语句是如何执行的?

mysql> select * from T where ID=10;

2.基础架构:一条sql更新语句是如何执行的?

mysql> update T set c=c+1 where ID=2;

 

redo log

(1)存储引擎的日志,InnoDB特有的;

(2)物理日志

(3)循环写,空间固定会用完;

binlog

(1)server端日志,所有引擎都有;

(2)逻辑日志

(3)追加写,文件写到一定大小,切换下一个,并不会覆盖之前的日志;

redolog的写入拆分成两个步骤:prepare和commit

redo log 和binlog都可以用于表示事务的提交状态,两阶段提交是为了维持这两个状态一致。

恢复:

注:正常执行redolog commit;崩溃恢复的时候可以接受redolog prepare并且binglog完整

3.事务隔离

MyISAM不支持事务,InnoDB 支持事务

读未提交:别人改数据的事务尚未提交,我在我的事务中也能读到。

读已提交:别人改数据的事务已经提交,我在我的事务中才能读到。

可重复读:别人改数据的事务已经提交,我在我的事务中也不去读。(对账的例子)

串行:我的事务尚未提交,别人就别想改数据。

https://blog.csdn.net/changhenshui1990/article/details/77161401

案例:http://www.javaseo.cn/article/88/

4.索引(上)

索引---目录:提供数据查询的效率

(1)哈希表:适合等值查询的场景

缺点:范围查找比较麻烦

哈希冲突:链表(两个key生成的N一样)

(2)有序数组:等值查找,范围查询性能都很好、只适合静态存储引擎

缺点:更新比较麻烦

(3)二叉搜索树:每个节点的左儿子小于父节点,父节点又小于右儿子

InnoDB的索引模型

B+树索引模型

mysql> create table T(

id int primary key,

k int not null,

name varchar(16),

index (k))engine=InnoDB;

索引类型:主建索引、非主建索引

主建索引的叶子节点存储:整行数据(聚簇索引),主建索引只要搜索id这个B+ Tree就可以拿到数据    

非主建索引叶子节点:主建的值(二级索引),普通索引先搜索索引拿到主建值,再到主建索引搜索一次(回表)

索引维护:

一个数据页满了,按照B+Tree算法,新增加一个数据页,叫做页分裂,会导致性能下降。空间利用率降低大概50%。当相邻的两个数据页利用率很低的时候会做数据页合并,合并的过程是分裂过程的逆过程。

 

性能和存储上来考虑,自增主建往往是更合理的选择;递增插入,追加,不会触发叶子节点分裂。

业务字段用作主建:(1)只有一个索引(2)该索引必须唯一索引。-------------------------直接将这个索引设置成主建,避免每次查询搜索两棵树。

5.索引(下)

(1)覆盖索引:select ID from T where k betwe 3 and 5  不需要回表(回到主键索引树搜索的过程,成为回表)

(2)前缀索引

(3)索引下推

总结:

1、覆盖索引:如果查询条件使用的是普通索引(或是联合索引的最左原则字段),查询结果是联合索引的字段或是主键,不用回表操作,直接返回结果,减少IO磁盘读写读取正行数据

2、最左前缀:联合索引的最左 N 个字段,也可以是字符串索引的最左 M 个字符

3、联合索引:根据创建联合索引的顺序,以最左原则进行where检索,比如(age,name)以age=1 或 age= 1 and name=‘张三’可以使用索引,单以name=‘张三’ 不会使用索引,考虑到存储空间的问题,还请根据业务需求,将查找频繁的数据进行靠左创建索引。

4、索引下推:like 'hello%’and age >10 检索,MySQL5.6版本之前,会对匹配的数据进行回表查询。5.6版本后,会先过滤掉age<10的数据,再进行回表查询,减少回表率,提升检索速度

6.数据库锁——行锁,表锁

锁:并发

(1)全局锁:对整个数据库实例加锁,全库数据备份的时候用;(InnoDB采用事务,可重复读可以支持;不支持事务的引擎不能够实现,采用FTWRL)  FTWRL——保证只读

(2)表级锁:表锁、元数据锁;

(3)行级锁:InnoDB(行锁)、MyIsAM(不支持行锁)

7.索引选择——唯一索引,普通索引

8.给字符串字段加索引

前缀索引

mysql> alter table SUser add index index1(email);

mysql> alter table SUser add index index2(email(6));

使用前缀索引,定义好长度,就可以做到既节省空间,又不用额外增加太多的查询成本

前缀索引对覆盖索引的影响:

其他方式: 倒序存储、hash字段

9.mysql "抖"了一下

WAL:先写日志,再写磁盘

刷脏页(flush)

(1)InnoDB的redo log满了的时候

(2)内存不够用了,先将脏页写到磁盘

(3)mysql系统空闲的时候

(4)mysql正常关闭的时候

10.数据删除,表文件大小不变

InnoDB:表结构(.frm)定义和数据(.ibd)。

delete 命令其实只是把记录的位置,或者数据页标记为“可复用”,但磁盘文件的大小是不会变的。----空洞

重建表可以收缩空间

11.count(*)的实现

MyISAM:一个表的总行数存在了磁盘上

InnoDB:把数据一行一行地从引擎里面读出来,然后累加

count(字段)

12.order by的原理

(1)全字段排序:

 

缺点:

1.造成sort_buffer中存放不下很多数据,因为除了排序字段还存放其他字段,对sort_buffer的利用效率不高

2.当所需排序数据量很大时,会有很多的临时文件,排序性能也会很差

优点:MySQL认为内存足够大时会优先选择全字段排序,因为这种方式比rowid 排序避免了一次回表操作

(2)rowId排序

优点:更好的利用内存的sort_buffer进行排序操作,尽量减少对磁盘的访问

缺点:回表的操作是随机IO,会造成大量的随机读,不一定就比全字段排序减少对磁盘的访问

13.mysql随机消息

mysql> select word from words order by rand() limit 3;

14.逻辑相同的sql语句性能相差很大

(1)条件字段函数

mysql> select count(*) from tradelog where month(t_modified)=7;

如果对字段做了函数计算,就用不上索引了,这是 MySQL 的规定。

对索引字段做函数操作,可能会破坏索引值的有序性,因此优化器就决定放弃走树搜索功能。

mysql> select count(*) from tradelog where

-> (t_modified >= '2016-7-1' and t_modified<'2016-8-1') or

-> (t_modified >= '2017-7-1' and t_modified<'2017-8-1') or

-> (t_modified >= '2018-7-1' and t_modified<'2018-8-1');

(2)隐式类型转换

mysql> select * from tradelog where tradeid=110717;

相当于 mysql> select * from tradelog where CAST(tradid AS signed int) = 110717;

对索引字段做函数操作,优化器会放弃走树搜索功能。

(3)隐式字符串编码转换

15.查一行数据也很慢

(1)查询长时间不返回:等MDL锁、等flush、等行锁

(2)查询慢:没有加索引,需要全表扫描;

16.幻读

间隙锁

17.mysql如何保证数据不丢失

18.mysql主备一致:binlog归档

binlog的格式:

(1)statement

(2)row

(3)mixed

19.mysql如何保证高可用

主备(写数据)、主从(读数据)------一主多从

20.mysql读写分离

21.join

select * from t1 straight_join t2 on (t1.b=t2.b) where t2.id<=50;

select * from t2 straight_join t1 on (t1.b=t2.b) where t2.id<=50;

第二条语句更好,小表作为驱动表;

22.分区表

CREATE TABLE `t` (

`ftime` datetime NOT NULL,

`c` int(11) DEFAULT NULL,

KEY (`ftime`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1

PARTITION BY RANGE (YEAR(ftime))

(PARTITION p_2017 VALUES LESS THAN (2017) ENGINE = InnoDB,

PARTITION p_2018 VALUES LESS THAN (2018) ENGINE = InnoDB,

PARTITION p_2019 VALUES LESS THAN (2019) ENGINE = InnoDB,

PARTITION p_others VALUES LESS THAN MAXVALUE ENGINE = InnoDB);

insert into t values('2017-4-1',1),('2018-4-1',1);

 

索引参考:https://blog.csdn.net/tongdanping/article/details/79878302

https://www.cnblogs.com/yuyue2014/p/3662005.html

http://blog.codinglabs.org/articles/theory-of-mysql-index.html

https://www.cnblogs.com/liqiangchn/p/9066686.html



相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
2月前
|
存储 SQL 关系型数据库
MySQL - 深入理解锁机制和实战场景
MySQL - 深入理解锁机制和实战场景
|
29天前
|
SQL 关系型数据库 MySQL
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(8.0版本升级篇)
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(8.0版本升级篇)
96 0
|
2天前
|
安全 关系型数据库 MySQL
node实战——后端koa结合jwt连接mysql实现权限登录(node后端就业储备知识)
node实战——后端koa结合jwt连接mysql实现权限登录(node后端就业储备知识)
11 3
|
2天前
|
SQL 关系型数据库 MySQL
不允许你不知道的 MySQL 优化实战(一)
不允许你不知道的 MySQL 优化实战(一)
10 2
|
5天前
|
关系型数据库 MySQL 中间件
【MySQL实战笔记】07 | 行锁功过:怎么减少行锁对性能的影响?-02 死锁和死锁检测
【4月更文挑战第19天】在高并发环境下,死锁发生在多个线程间循环等待资源时,导致无限期等待。MySQL中,死锁可通过`innodb_lock_wait_timeout`参数设置超时或`innodb_deadlock_detect`开启死锁检测来解决。默认的50s超时可能不适用于在线服务,而频繁检测会消耗大量CPU。应对热点行更新引发的性能问题,可以暂时关闭死锁检测(风险是产生大量超时),控制并发度,或通过分散记录减少锁冲突,例如将数据分拆到多行以降低死锁概率。
19 1
|
8天前
|
SQL 关系型数据库 MySQL
Python与MySQL数据库交互:面试实战
【4月更文挑战第16天】本文介绍了Python与MySQL交互的面试重点,包括使用`mysql-connector-python`或`pymysql`连接数据库、执行SQL查询、异常处理、防止SQL注入、事务管理和ORM框架。易错点包括忘记关闭连接、忽视异常处理、硬编码SQL、忽略事务及过度依赖低效查询。通过理解这些问题和提供策略,可提升面试表现。
29 6
|
15天前
|
存储 关系型数据库 MySQL
【MySQL实战笔记】 04 | 深入浅出索引(上)-02
【4月更文挑战第9天】InnoDB数据库使用B+树作为索引模型,其中主键索引的叶子节点存储完整行数据,非主键索引则存储主键值。主键查询只需搜索一棵树,而非主键查询需两次搜索,因此推荐使用主键查询以提高效率。在插入新值时,B+树需要维护有序性,可能导致数据页分裂影响性能。自增主键在插入时可避免数据挪动和页分裂,且占用存储空间小,通常更为理想。然而,如果场景仅需唯一索引,可直接设为主键以减少查询步骤。
16 1
【MySQL实战笔记】 04 | 深入浅出索引(上)-02
|
17天前
|
存储 SQL 关系型数据库
【MySQL实战笔记】03.事务隔离:为什么你改了我还看不见?-02
【4月更文挑战第7天】数据库通过视图实现事务隔离,不同隔离级别如读未提交、读已提交、可重复读和串行化采用不同策略。以可重复读为例,MySQL使用多版本并发控制(MVCC),每个事务有其独立的视图。回滚日志在无更早视图时被删除。长事务可能导致大量存储占用,应避免。事务启动可显式用`begin`或设置`autocommit=0`,但后者可能意外开启长事务。建议使用`autocommit=1`并显式管理事务,若需减少交互,可使用`commit work and chain`。
30 5
|
19天前
|
SQL 存储 关系型数据库
【MySQL实战笔记】02.一条SQL更新语句是如何执行的-2
【4月更文挑战第5天】两阶段提交是为确保`redo log`和`binlog`逻辑一致,避免数据不一致。若先写`redo log`, crash后数据可能丢失,导致恢复后状态错误;若先写`binlog`,crash则可能导致重复事务,影响数据库一致性。一天一备相较于一周一备,能缩短“最长恢复时间”,但需权衡额外的存储成本。
16 1
|
29天前
|
SQL 关系型数据库 MySQL
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)(一)
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)
30 0