MySql
数据库最大连接数为 151
端口为3306
一条sql的执行语句是怎样的?
select * from user_info where userid=1 ??
- 首先建立客户端与数据库服务器之间的连接 client(客户端)
- 查看数据库相关的线程数 show global status like ‘Thread%’;
- 客户端多久不活动自动关闭连接
- show global variables like ‘wait_timeout’;
- show global variables like ‘interactive_timeout’;
- 查看客户daunt最大连接数
- show global variables like ‘max_connections’;
- 分析器解析器进行词法和语法的解析==(预处理器)==
- 词法解析 把每一个单词解析
- 语法分析 例如:where 后是否加入条件----最后得到一个解析树一样的结构
- 语义解析 mysql中的预处理器进行处理 例如:所查的这个表是否存在,列名是否存在等
- ==优化处理器==进行选择
- 可以为我们进行选择执行路径与索引的选择,执行计划
- 执行计划 ExPlanin + sql语句
- 存储引擎 (不同的业务需求) 现在默认为 innodb
- innodb
- memory
- myisam
- 操作引擎—返回结果
数据库的索引到底是什么?(空间换时间)
一种排序的数据结果,协助快速查询更新表中的数据。
建立索引: alter table 表名 add INDEX 索引名(字段名)
尽量在自增的并且有序的字段上建立索引
- 存储结构
- 有序数组(查找速度快,但是插入删除慢,因为下标会大量挪动)
- 单链表
- 二叉数:但是特殊性情况下会退化成单链表结构
- 平衡二叉树(AV.L树)
- 左右子树的深度差绝对值不能超过1
- 通过树的左旋、右旋生成此结构
- 多路平衡树—B树
-
B+树–关键字有多少,度就有多少
- 关键字数与度相同
- 内节存储数据,只有在叶子节点上存在数据点
- 叶子节点上有指向双向的指针,相当于形成了双向的链表
-
B+树的优势
- B树的能力B+树都有
- 扫描表能力更强
- 磁盘读写能力更强,磁盘io操作更少
- 排序,范围查找能力更强
- 效率更稳定(平均效率更恒定)
为什么不使用红黑树?
主要是考虑到树的深度会影响查找的效率。—在磁盘中效率会变慢
-
数据存储
- myisam存储结构
- 索引与数据分开存放
- ‘innodb中
- 以索引来组织数据的存放(索引即数据)
- myisam存储结构
-
innodb中的索引:
聚集索引--主键索引 - 索引的逻辑顺序与数据行的物理存放顺序是一致的 二级索引 - 会找到第一个不为空值的索引为聚集索引 表内没有索引 - 自动生成一个隐藏的字段 _rowid
-
列的离散度(离散度非常低的 没必要创建索引—相反可能会变慢)
- 重复度越高 —列的离散度越低
- 重复性越低 —列的离散度越高
-
联合索引的最左匹配原则
- alter table 表名 index 索引名 (‘aaa’,‘vvvv’);
-
什么时候索引失效
- 在索引列上使用函数,表达式,运算符
- 出现了隐形的字符转换,如字符串未加引号
- like 前面使用了 ‘%’ ----因为对比时是从左向右对比的
- 负向查询 !=, <> , not in
Mysql的事物与锁
什么是事物?
> 是一个数据库管理系统中的逻辑单位
- 事物的特性 ACID
- 原子性
- 要么全部成功,要么全部失败
- 使用回滚的做法
- innodb的 undo log日志
- 持久性
- 只要事物提交成功,这条数据修改即为永久性(写入磁盘)
- redo log日志来实现
- 隔离性
- 事物之间需要隔离,根据事物隔离性级别来进行事物之间操作
- 一致性
- 根据原子性,持久性,一致性来决定了一致性
- 原子性
- 增删改的语句 会自动开启事物
- 手动开启事务
- begin; ----开启事物
- show variables like ‘autocommit’ -----进行开启事务后是否自动提交
- 不自动提交 使用 commit;
-
事物并发问题?
-
脏读
-
前后两次读取不一致,其中一个事物还未提交就被查询(如果未提交的回滚就会有问题)
-
-
不可重复读
-
事物已提交,A事物执行比较长,第一次读取时B未提交,第二次读取 B事物已经更改,发生在update和delete操作中
-
-
幻读
-
只有插入的操作才会是幻读,A事物读取时是一条数据,但是B事物插入了数据,A事物第二次读取 发现多出了几条数据,所以为幻读
-
1.事物隔离级别解决脏读,不可重复读,幻读
-
RU 未提交读
- 什么都未提交
-
RC
- 已提交读,可以解决脏读
-
RR 可重复读
- 可能搞不定幻读
-
Serializable 串行化
-
全部搞定
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W0ZtZVRu-1609767468671)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20201218001552165.png)]
-
- 如何解决同一个事物读取的数据一致?
- mvcc 对第一次读的数据进行快照,之后的读都是读取的快照
- 会对每一个列进行创建事物版本号–(创建版本号,修改版本号)
- 能看到本事物开启之前的数据修改以及之后本事物的修改
- 不能看到的是其他事物对于该数据的修改 增加 删除修改等
- lbcc 加锁阻止其他事物对数据进行操作
- mvcc 对第一次读的数据进行快照,之后的读都是读取的快照
-
锁的基本类型
- 表锁与行锁
- 加锁效率 表锁的效率比行锁效率高
- 冲突概率 表锁大于行锁
- 并发性能 表锁小于行锁
行锁,锁主要是解决资源竞争的问题,锁住了数据
- 共享锁
- 排他锁 x锁
- 自动 insert delete update 自动默认排他锁
- select * from user FOR UPDATE 手动排他锁
innodb锁怎样实现
- innodb 的行锁到底锁住了什么?
- 锁住了索引,如果没有用到索引就回全表扫描–相当于锁住全表
- 该索引不能失效,否则行锁 升级为 表锁