MySQL知识点总结

MySQL知识点总结,第1张

只要字段值还可以继续拆分,就不满足第一范式。

范式设计得越详细,对某些实际 *** 作可能会更好,但并非都有好处,需要对项目的实际情况进行设定。

在满足第一范式的前提下,其他列都必须完全依赖于主键列。 如果出现不完全依赖,只可能发生在联合主键的情况下:

实际上,在这张订单表中,product_name 只依赖于 product_id ,customer_name 只依赖于 customer_id。也就是说,product_name 和 customer_id 是没用关系的,customer_name 和 product_id 也是没有关系的。

这就不满足第二范式:其他列都必须完全依赖于主键列!

拆分之后,myorder 表中的 product_id 和 customer_id 完全依赖于 order_id 主键,而 product 和 customer 表中的其他字段又完全依赖于主键。满足了第二范式的设计!

在满足第二范式的前提下,除了主键列之外,其他列之间不能有传递依赖关系。

表中的 customer_phone 有可能依赖于 order_id 、 customer_id 两列,也就不满足了第三范式的设计:其他列之间不能有传递依赖关系。

修改后就不存在其他列之间的传递依赖关系,其他列都只依赖于主键列,满足了第三范式的设计!

查询每门课的平均成绩。

查询 score 表中至少有 2 名学生选修,并以 3 开头的课程的平均分数。

分析表发现,至少有 2 名学生选修的课程是 3-105 、3-245 、6-166 ,以 3 开头的课程是 3-105 、3-245。也就是说,我们要查询所有 3-105 和 3-245 的 degree 平均分。

查询所有学生的 name,以及该学生在 score 表中对应的 c_no 和 degree 。

通过分析可以发现,只要把 score 表中的 s_no 字段值替换成 student 表中对应的 name 字段值就可以了,如何做呢?

查询所有学生的 no 、课程名称 ( course 表中的 name ) 和成绩 ( score 表中的 degree ) 列。

只有 score 关联学生的 no ,因此只要查询 score 表,就能找出所有和学生相关的 no 和 degree :

然后查询 course 表:

只要把 score 表中的 c_no 替换成 course 表中对应的 name 字段值就可以了。

查询所有学生的 name 、课程名 ( course 表中的 name ) 和 degree 。

只有 score 表中关联学生的学号和课堂号,我们只要围绕着 score 这张表查询就好了。

只要把 s_no 和 c_no 替换成 student 和 srouse 表中对应的 name 字段值就好了。

首先把 s_no 替换成 student 表中的 name 字段:

再把 c_no 替换成 course 表中的 name 字段:

查询 95031 班学生每门课程的平均成绩。

在 score 表中根据 student 表的学生编号筛选出学生的课堂号和成绩:

这时只要将 c_no 分组一下就能得出 95031 班学生每门课的平均成绩:

查询在 3-105 课程中,所有成绩高于 109 号同学的记录。

首先筛选出课堂号为 3-105 ,在找出所有成绩高于 109 号同学的的行。

查询所有成绩高于 109 号同学的 3-105 课程成绩记录。

查询所有和 101 、108 号学生同年出生的 no 、name 、birthday 列。

查询 '张旭' 教师任课的学生成绩表。

首先找到教师编号:

通过 sourse 表找到该教师课程号:

通过筛选出的课程号查询成绩表:

查询某选修课程多于5个同学的教师姓名。

首先在 teacher 表中,根据 no 字段来判断该教师的同一门课程是否有至少5名学员选修:

查看和教师编号有有关的表的信息:

我们已经找到和教师编号有关的字段就在 course 表中,但是还无法知道哪门课程至少有5名学生选修,所以还需要根据 score 表来查询:

根据筛选出来的课程号,找出在某课程中,拥有至少5名学员的教师编号:

在 teacher 表中,根据筛选出来的教师编号找到教师姓名:

查询 “计算机系” 课程的成绩表。

思路是,先找出 course 表中所有 计算机系 课程的编号,然后根据这个编号查询 score 表。

查询 计算机系 与 电子工程系 中的不同职称的教师。

查询课程 3-105 且成绩 至少 高于 3-245 的 score 表。

查询课程 3-105 且成绩高于 3-245 的 score 表。

查询某课程成绩比该课程平均成绩低的 score 表。

查询所有任课 ( 在 course 表里有课程 ) 教师的 name 和 department

查询 student 表中至少有 2 名男生的 class 。

查询 student 表中不姓 "王" 的同学记录。

查询 student 表中每个学生的姓名和年龄。

查询 student 表中最大和最小的 birthday 值。

以 class 和 birthday 从大到小的顺序查询 student 表。

查询 "男" 教师及其所上的课程。

查询最高分同学的 score 表。

查询和 "李军" 同性别的所有同学 name 。

查询和 "李军" 同性别且同班的同学 name 。

查询所有选修 "计算机导论" 课程的 "男" 同学成绩表。

需要的 "计算机导论" 和性别为 "男" 的编号可以在 course 和 student 表中找到。

建立一个 grade 表代表学生的成绩等级,并插入数据

查询所有学生的 s_no 、c_no 和 grade 列。

思路是,使用区间 ( BETWEEN ) 查询,判断学生的成绩 ( degree ) 在 grade 表的 low 和 upp 之间。

准备用于测试连接查询的数据:

分析两张表发现,person 表并没有为 cardId 字段设置一个在 card 表中对应的 id 外键。如果设置了的话,person 中 cardId 字段值为 6 的行就插不进去,因为该 cardId 值在 card 表中并没有。

要查询这两张表中有关系的数据,可以使用 INNER JOIN ( 内连接 ) 将它们连接在一起。

完整显示左边的表 ( person ) ,右边的表如果符合条件就显示,不符合则补 NULL 。

完整显示右边的表 ( card ) ,左边的表如果符合条件就显示,不符合则补 NULL 。

完整显示两张表的全部数据。

在 MySQL 中,事务其实是一个最小的不可分割的工作单元。事务能够 保证一个业务的完整性

比如我们的银行转账:

在实际项目中,假设只有一条 SQL 语句执行成功,而另外一条执行失败了,就会出现数据前后不一致。

因此,在执行多条有关联 SQL 语句时, 事务 可能会要求这些 SQL 语句要么同时执行成功,要么就都执行失败。

在 MySQL 中,事务的 自动提交 状态默认是开启的。

自动提交的作用 :当我们执行一条 SQL 语句的时候,其产生的效果就会立即体现出来,且不能 回滚

什么是回滚?举个例子:

可以看到,在执行插入语句后数据立刻生效,原因是 MySQL 中的事务自动将它 提交 到了数据库中。那么所谓 回滚 的意思就是,撤销执行过的所有 SQL 语句,使其回滚到 最后一次提交 数据时的状态。

在 MySQL 中使用 ROLLBACK 执行回滚:

由于所有执行过的 SQL 语句都已经被提交过了,所以数据并没有发生回滚。那如何让数据可以发生回滚?

将自动提交关闭后,测试数据回滚:

那如何将虚拟的数据真正提交到数据库中?使用 COMMIT :

事务的实际应用 ,让我们再回到银行转账项目:

这时假设在转账时发生了意外,就可以使用 ROLLBACK 回滚到最后一次提交的状态:

这时我们又回到了发生意外之前的状态,也就是说,事务给我们提供了一个可以反悔的机会。假设数据没有发生意外,这时可以手动将数据真正提交到数据表中:COMMIT 。

事务的默认提交被开启 ( @@AUTOCOMMIT = 1 ) 后,此时就不能使用事务回滚了。但是我们还可以手动开启一个事务处理事件,使其可以发生回滚:

仍然使用 COMMIT 提交数据,提交后无法再发生本次事务的回滚。

事务的四大特征:

事务的隔离性可分为四种 ( 性能从低到高 )

查看当前数据库的默认隔离级别:

修改隔离级别:

测试 READ UNCOMMITTED ( 读取未提交 ) 的隔离性:

由于小明的转账是在新开启的事务上进行 *** 作的,而该 *** 作的结果是可以被其他事务(另一方的淘宝店)看见的,因此淘宝店的查询结果是正确的,淘宝店确认到账。但就在这时,如果小明在它所处的事务上又执行了 ROLLBACK 命令,会发生什么?

这就是所谓的 脏读 ,一个事务读取到另外一个事务还未提交的数据。这在实际开发中是不允许出现的。

把隔离级别设置为 READ COMMITTED

这样,再有新的事务连接进来时,它们就只能查询到已经提交过的事务数据了。但是对于当前事务来说,它们看到的还是未提交的数据,例如:

但是这样还有问题,那就是假设一个事务在 *** 作数据时,其他事务干扰了这个事务的数据。例如:

虽然 READ COMMITTED 让我们只能读取到其他事务已经提交的数据,但还是会出现问题,就是 在读取同一个表的数据时,可能会发生前后不一致的情况。* 这被称为* 不可重复读现象 ( READ COMMITTED )

将隔离级别设置为 REPEATABLE READ ( 可被重复读取 ) :

测试 REPEATABLE READ ,假设在两个不同的连接上分别执行 START TRANSACTION :

当前事务开启后,没提交之前,查询不到,提交后可以被查询到。但是,在提交之前其他事务被开启了,那么在这条事务线上,就不会查询到当前有 *** 作事务的连接。相当于开辟出一条单独的线程。

无论小张是否执行过 COMMIT ,在小王这边,都不会查询到小张的事务记录,而是只会查询到自己所处事务的记录:

这是 因为小王在此之前开启了一个新的事务 ( START TRANSACTION ) * ,那么* 在他的这条新事务的线上,跟其他事务是没有联系的 ,也就是说,此时如果其他事务正在 *** 作数据,它是不知道的。

然而事实是,在真实的数据表中,小张已经插入了一条数据。但是小王此时并不知道,也插入了同一条数据,会发生什么呢?

报错了, *** 作被告知已存在主键为 6 的字段。这种现象也被称为 幻读,一个事务提交的数据,不能被其他事务读取到

顾名思义,就是所有事务的 写入 *** 作 全都是串行化的。什么意思?把隔离级别修改成 SERIALIZABLE :

还是拿小张和小王来举例:

此时会发生什么呢?由于现在的隔离级别是 SERIALIZABLE ( 串行化 ) ,串行化的意思就是:假设把所有的事务都放在一个串行的队列中,那么所有的事务都会按照 固定顺序执行 ,执行完一个事务后再继续执行下一个事务的 写入 *** 作 ( 这意味着队列中同时只能执行一个事务的写入 *** 作 ) 。

根据这个解释,小王在插入数据时,会出现等待状态,直到小张执行 COMMIT 结束它所处的事务,或者出现等待超时。

转载: https://github.com/baa-god/sql_node/blob/master/mysql/

首先说说索引 优点 :最大的好处无疑就是提高查询效率。有的索引还能保证数据的唯一性,比如唯一索引。

而它的 坏处 也很明显:索引也是文件,我们在创建索引时,也会创建额外的文件,所以会占用一些硬盘空间。其次,索引也需要维护,我们在增加删除数据的时候,索引也需要去变化维护。当一个表的索引多了以后,资源消耗是很大的,所以必须结合实际业务再去确定给哪些列加索引。

再说说索引的基本结构。一说到这里肯定会脱口而出:B+树!了解B+树前先要了解二叉查找树和二叉平衡树。 二叉查找树 :左节点比父节点小,右节点比父节点大,所以二叉查找树的中序遍历就是树的各个节点从小到大的排序。 二叉平衡树 :左右子树高度差不能大于1。B+树就是结合了它们的特点,当然,不一定是二叉树。

为什么要有二叉查找树的特点?? 因为查找效率快,二分查找在这种结构下,查找效率是很快的。 那为什么要有平衡树的特点呢? 试想,如果不维护一颗树的平衡性,当插入一些数据后,树的形态有可能变得很极端,比如左子树一个数据没有,而全在右子树上,这种情况下,二分查找和遍历有什么区别呢?而就是因为这些特点需要去维护,所以就有了上面提到的缺点,当索引很多后,反而增加了系统的负担。

接着说B+树。 它的结构如下

可以发现,叶子节点其实是一个 双向循环链表 ,这种结构的好处就是,在范围查询的时候,我只用找到一个数据,就可以直接返回剩余的数据了。比如找小于30的,只用找到30,其余的直接通过叶子节点间的指针就可以找到。再说说其他特点: 数据只存在于叶子节点 。当叶子节点满了,如果再添加数据,就会拆分叶子节点,父节点就多了个子节点。如果父节点的位置也满了,就会扩充高度,就是拆分父节点,如25 50 75拆分成:25为左子树,75为右子树,50变成新的头节点,此时B+树的高度变成了3。它们的扩充的规律如下表,Leaf Page是叶子节点,index Page是非叶子节点。

再说说B树 ,B树相比较B+树,它所有节点都存放数据,所以在查找数据时,B树有可能没到达叶子节点就结束了。再者,B树的叶子节点间不存在指针。

最后说说Hash索引 ,相较于B+树,Hash索引最大的优点就是查找数据快。但是Hash索引最大的问题就是不支持范围查询。试想,如果查询小于30的数据,hash函数是根据数据的值找到其对应的位置,谁又知道小于30的有哪几个数据。而B+树正好相反,范围查询是它的强项。

附录: Hash到底是啥?? 哈希中文名散列,哈希只是它的音译。 为啥都说Hash快?? 首先有一块哈希表(散列表),它的数据结构是个数组,一个任意长度的数据通过hash函数都可以变成一个固定长度的数据,叫hash值。然后通过hash值确定在数组中的位置,相同数据的hash值是相同的,所以我们存储一个数据以后,只需O(1)的时间复杂度就可以找到数据。 那hash函数又是啥?? 算术运算或位运算,很多应用里都有hash函数,但实际运算过程大不一样。这是Java里String的hashCode方法:

publicint hashCode() {

}

还有一个问题,hash函数计算出来的hash值有可能存在碰撞,即两个不同的数据可能存在相同的hash值,在MySQL或其他的应用中,如Java的HashMap等,如果存在碰撞就会以当前数组位置为头节点,转变成一个链表。

说到这里也清楚了为啥Java中引用类型要同时重写hashCode和equals了。两个对象,实例就算一模一样,它们的hash值也不相等, 为啥不相等?? 默认的Object的hashCode方法会根据对象来计算hash值的,实例相同,但它们还是两个不同的对象啊,所以我们重写hashCode时,最简单的方法就是调用Object的hashCode方法,然后传入该引用类型的属性,让hashCode方法只根据这几个属性来计算,那么实例相同的话,它们的hash值也会相等。等hashCode比较完后,如果相等再比较实例内容,也就是equals,确保不是hash碰撞。

索引的分类

如果我们指定了一个主键,那么这个主键就是主键索引。如果我们没有指定,Mysql就会自动找一个非空的唯一索引当主键。如果没有这种字段,Mysql就会创建一个大小为6字节的自增主键。如果有多个非空的唯一索引,那么就让第一个定义为唯一索引的字段当主键,注意,是第一个定义,而不是建表时出现在前面的。

对于辅助索引来说,它们的B+树结构稍微有点特殊,它们的叶子节点存储的是主键,而不是整个数据。所以在大部分情况下,使用辅助索引查找数据,需要二次查找。但并不是所有情况都需要二次查找。比如查找的数据正好就是当前索引字段的值,那么直接返回就行。这里提一句,B+树的key就是对应索引字段的内容。

而辅助索引又有一些分类:唯一索引:不能出现重复的值,也算一种约束。普通索引:可以重复、可以为空,一般就是查询时用到。前缀索引:只适用于字符串类型数据,对字符串前几个字符创建索引。全文索引:作用是检测大文本数据中某个关键字,这也是搜索引擎的一种技术。

注意,聚集索引、非聚集索引和前面几个索引的分类并不是一个层面上的。上面的几个分类是从索引的作用来分析的。聚集、非聚集索引是从索引文件上区分的。主键索引就属于聚集索引,即索引和数据存放在一起,叶子节点存放的就是数据。数据表的.idb文件就是存放该表的索引和数据。

辅助索引属于非聚集索引,说到这也就明白了。索引和数据不存放在一起的就是非聚集索引。在MYISAM引擎中,数据表的.MYI文件包含了表的索引, 该表的 叶子节点存储索引和索引对应数据的指针,指向.MYD文件的数据。

索引的几点使用经验

经常被查询的字段;经常作为条件查询的字段;经常用于外键连接或普通的连表查询时进行相等比较字段;不为null的字段;如果是多条件查询,最好创建联合索引,因为联合索引只有一个索引文件。

经常被更新的字段、不经常被查询的字段、存在相同功能的字段


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/6121886.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-15
下一篇 2023-03-15

发表评论

登录后才能评论

评论列表(0条)

保存