赞
踩
MySQL是一个关系型数据库,它采用表的形式来存储数据。你可以理解成是Excel表格,既然是表的形式存储数据,就有表结构(行和列)。行代表每一行数据,列代表该行中的每个值。列上的值是有数据类型的,比如:整数、字符串、日期等等。
第一范式1NF
确保数据库表字段的原子性。
比如字段 userInfo
: 广东省 10086'
,依照第一范式必须拆分成 userInfo
: 广东省
userTel
:10086
两个字段。
第二范式2NF
首先要满足第一范式,另外包含两部分内容,一是表必须有一个主键;二是非主键列必须完全依赖于主键,而不能只依赖于主键的一部分。
举个例子。假定选课关系表为student_course
(student_no, student_name, age, course_name, grade, credit),主键为(student_no, course_name)。其中学分完全依赖于课程名称,姓名年龄完全依赖学号,不符合第二范式,会导致数据冗余(学生选n门课,姓名年龄有n条记录)、插入异常(插入一门新课,因为没有学号,无法保存新课记录)等问题。
应该拆分成三个表:学生:student
(stuent_no, student_name, 年龄);课程:course
(course_name, credit);选课关系:student_course_relation
(student_no, course_name, grade)。
第三范式3NF
首先要满足第二范式,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。
假定学生关系表为Student(student_no, student_name, age, academy_id, academy_telephone),主键为"学号",其中学院id依赖于学号,而学院地点和学院电话依赖于学院id,存在传递依赖,不符合第三范式。
可以把学生关系表分为如下两个表:学生:(student_no, student_name, age, academy_id);学院:(academy_id, academy_telephone)。
2NF和3NF的区别?
本文已经收录到Github仓库,该仓库包含计算机基础、Java基础、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等核心知识点,欢迎star~
如果访问不了Github,可以访问gitee地址。
事务特性ACID:原子性(Atomicity
)、一致性(Consistency
)、隔离性(Isolation
)、持久性(Durability
)。
read committed
,一个事务只能读到已经提交的修改。先了解下几个概念:脏读、不可重复读、幻读。
不可重复读和脏读的区别是,脏读是某一事务读取了另一个事务未提交的脏数据,而不可重复读则是读取了前一事务提交的数据。
事务隔离就是为了解决上面提到的脏读、不可重复读、幻读这几个问题。
MySQL数据库为我们提供的四种隔离级别:
查看隔离级别:
select @@transaction_isolation;
设置隔离级别:
set session transaction isolation level read uncommitted;
生产环境大多使用RC。为什么不是RR呢?
可重复读(Repeatable Read),简称为RR
读已提交(Read Commited),简称为RC
缘由一:在RR隔离级别下,存在间隙锁,导致出现死锁的几率比RC大的多!
缘由二:在RR隔离级别下,条件列未命中索引会锁表!而在RC隔离级别下,只锁行!
也就是说,RC的并发性高于RR。
并且大部分场景下,不可重复读问题是可以接受的。毕竟数据都已经提交了,读出来本身就没有太大问题!
我们平时可以在编辑器上输入各种中文英文字母,但这些都是给人读的,不是给计算机读的,其实计算机真正保存和传输数据都是以二进制0101的格式进行的。
那么就需要有一个规则,把中文和英文字母转化为二进制。其中d对应十六进制下的64,它可以转换为01二进制的格式。于是字母和数字就这样一一对应起来了,这就是ASCII编码格式。
它用一个字节,也就是8位
来标识字符,基础符号有128个,扩展符号也是128个。也就只能表示下英文字母和数字。
这明显不够用。于是,为了标识中文,出现了GB2312的编码格式。为了标识希腊语,出现了greek编码格式,为了标识俄语,整了cp866编码格式。
为了统一它们,于是出现了Unicode编码格式,它用了2~4个字节来表示字符,这样理论上所有符号都能被收录进去,并且它还完全兼容ASCII的编码,也就是说,同样是字母d,在ASCII用64表示,在Unicode里还是用64来表示。
但不同的地方是ASCII编码用1个字节来表示,而Unicode用则两个字节来表示。
同样都是字母d,unicode比ascii多使用了一个字节,如下:
- D ASCII: 01100100
- D Unicode: 00000000 01100100
可以看到,上面的unicode编码,前面的都是0,其实用不上,但还占了个字节,有点浪费。如果我们能做到该隐藏时隐藏,这样就能省下不少空间,按这个思路,就是就有了UTF-8编码。
总结一下,按照一定规则把符号和二进制码对应起来,这就是编码。而把n多这种已经编码的字符聚在一起,就是我们常说的字符集。
比如utf-8字符集就是所有utf-8编码格式的字符的合集。
想看下mysql支持哪些字符集。可以执行 show charset;
上面提到utf-8是在unicode的基础上做的优化,既然unicode有办法表示所有字符,那utf-8也一样可以表示所有字符,为了避免混淆,我在后面叫它大utf8。
mysql支持的字符集中有utf8和utf8mb4。
先说utf8mb4编码,mb4就是most bytes 4的意思,从上图最右边的Maxlen
可以看到,它最大支持用4个字节来表示字符,它几乎可以用来表示目前已知的所有的字符。
再说mysql字符集里的utf8,它是数据库的默认字符集。但注意,此utf8非彼utf8,我们叫它小utf8字符集。为什么这么说,因为从Maxlen可以看出,它最多支持用3个字节去表示字符,按utf8mb4的命名方式,准确点应该叫它utf8mb3。
utf8 就像是阉割版的utf8mb4,只支持部分字符。比如emoji
表情,它就不支持。
而mysql支持的字符集里,第三列,collation,它是指字符集的比较规则。
比如,"debug"和"Debug"是同一个单词,但它们大小写不同,该不该判为同一个单词呢。
这时候就需要用到collation了。
通过SHOW COLLATION WHERE Charset = 'utf8mb4';
可以查看到utf8mb4
下支持什么比较规则。
如果collation = utf8mb4_general_ci
,是指使用utf8mb4字符集的前提下,挨个字符进行比较(general
),并且不区分大小写(_ci,case insensitice
)。
这种情况下,"debug"和"Debug"是同一个单词。
如果改成collation=utf8mb4_bin
,就是指挨个比较二进制位大小。
于是"debug"和"Debug"就不是同一个单词。
那utf8mb4对比utf8有什么劣势吗?
我们知道数据库表里,字段类型如果是char(2)
的话,里面的2
是指字符个数,也就是说不管这张表用的是什么编码的字符集,都能放上2个字符。
而char又是固定长度,为了能放下2个utf8mb4的字符,char会默认保留2*4(maxlen=4)= 8
个字节的空间。
如果是utf8mb3,则会默认保留 2 * 3 (maxlen=3) = 6
个字节的空间。也就是说,在这种情况下,utf8mb4会比utf8mb3多使用一些空间。
索引是存储引擎用于提高数据库表的访问速度的一种数据结构。它可以比作一本字典的目录,可以帮你快速找到对应的记录。
索引一般存储在磁盘的文件中,它是占用物理空间的。
优点:
缺点:
数据是存储在磁盘上的,查询数据时,如果没有索引,会加载所有的数据到内存,依次进行检索,读取磁盘次数较多。有了索引,就不需要加载所有数据,因为B+树的高度一般在2-4层,最多只需要读取2-4次磁盘,查询速度大大提升。
where
条件中用不到的字段不适合建立索引索引的数据结构主要有B+树和哈希表,对应的索引分别为B+树索引和哈希索引。InnoDB引擎的索引类型有B+树索引和哈希索引,默认的索引类型为B+树索引。
B+树索引
B+ 树是基于B 树和叶子节点顺序访问指针进行实现,它具有B树的平衡性,并且通过顺序访问指针来提高区间查询的性能。
在 B+ 树中,节点中的 key
从左到右递增排列,如果某个指针的左右相邻 key
分别是 keyi 和 keyi+1,则该指针指向节点的所有 key
大于等于 keyi 且小于等于 keyi+1。
进行查找操作时,首先在根节点进行二分查找,找到key
所在的指针,然后递归地在指针所指向的节点进行查找。直到查找到叶子节点,然后在叶子节点上进行二分查找,找出key
所对应的数据项。
MySQL 数据库使用最多的索引类型是BTREE
索引,底层基于B+树数据结构来实现。
- mysql> show index from blog\G;
- *************************** 1. row ***************************
- Table: blog
- Non_unique: 0
- Key_name: PRIMARY
- Seq_in_index: 1
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。