没有合适的资源?快使用搜索试试~ 我知道了~
1. 通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性 2. 可以大大加快 数据的检索速度(大大减少的检索的数据量), 这也是创建索引的最主要的原因 3
资源详情
资源评论
资源推荐
1
数据库设计三大范式
1.1. 第一范式(确保每列保持原子性)
如果数据库表中的所有字段值都是不可分解的原子值,该数据库表满足了第一范式。
1.2. 第二范式(确保表中的每列都和主键相关)
第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关
(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,
不可以把多种数据保存在同一张数据库表中。
比如要设计一个订单信息表,将订单编号和商品编号作为数据库表的联合主键。
产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名
称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里
违反了第二范式的设计原则。而如果把这个订单信息表进行拆分,把商品信息分离到另一
个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示。
2
这样设计,在很大程度上减小了数据库的冗余。如果要获取订单的商品信息,使用商品编
号到商品信息表中查询即可。
1.3. 第三范式(确保每列都和主键列直接相关,而不是间接相关)
第三范式需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关。
比如在设计一个订单数据表的时候,可以将客户编号作为一个外键和订单表建立相应的关
系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。如下
面这两个表所示的设计就是一个满足第三范式的数据库表。
这样在查询订单信息的时候,就可以使用客户编号来引用客户信息表中的记录,也不必在
订单信息表中多次输入客户信息的内容,减小了数据冗余。
数据的读取
1. InnoDB 的数据是按「数据页」为单位来读写的,也就是说,当需要读一条记录的时候,
并不是将这个记录本身从磁盘读出来,而是以页为单位,将其整体读入内存。
2. 数据库的 I/O 操作的最小单位是页,InnoDB 数据页的默认大小是 16KB,意味着数据
库每次读写都是以 16KB 为单位的,一次最少从磁盘中读取 16K 的内容到内存中,一
次最少把内存中的 16K 内容刷新到磁盘中。
数据页的结构
数据页的主要作用是存储记录,也就是数据库的数据
3
用户记录及页目录的组织方式
数据页中的记录按照「主键」顺序组成单向链表,单向链表的特点就是插入、删除非常方
便,但是检索效率不高,最差的情况下需要遍历链表上的所有节点才能完成检索。
数据页中有一个页目录,起到记录的索引作用
1. 将所有的记录划分成几个组,这些记录包括最小记录和最大记录,但不包括标记为“已删
4
除”的记录;
2. 每个记录组的最后一条记录就是组内最大的那条记录,并且最后一条记录的头信息中会
存储该组一共有多少条记录,作为 n_owned 字段(上图中粉红色字段)
3. 页目录用来存储每组最后一条记录的地址偏移量,这些地址偏移量会按照先后顺序存储
起来,每组的地址偏移量也被称之为槽(slot),每个槽相当于指针指向了不同组的最后
一个记录。
4. InnoDB 对每个分组中的记录条数都是有规定的,槽内的记录就只有几条:
第一个分组中的记录只能有 1 条记录;
最后一个分组中的记录条数范围只能在 1-8 条之间;
剩下的分组中记录条数范围只能在 4-8 条之间。
从图可以看到,页目录就是由多个槽组成的,槽相当于分组记录的索引。然后,因为记录
是按照「主键值」从小到大排序的,所以我们通过槽查找记录时,可以使用二分法快速定
位要查询的记录在哪个槽(哪个记录分组),定位到槽后,再遍历槽内的所有记录,找到
对应的记录,无需从最小记录开始遍历整个页中的记录链表。
为什么推荐使用自增 ID 作为主键?
自增 ID 可以保证每次插入时 B+索引是从右边扩展的,可以避免 B+树和频繁合并和分裂
(对比使用 UUID)。如果使用字符串主键和随机主键,会使得数据随机插入,效率比较
差。
如果表使用自增主键,那么每次插入新的记录,记录就会顺序添加到当前索引节点的后续
位置,当一页写满,就会自动开辟一个新的页。 如果使用非自增主键(如果身份证号或学
号等),由于每次插入主键的值近似于随机,因此每次新纪录都要被插到现有索引页得中
间某个位置, 频繁的移动、分页操作造成了大量的碎片,得到了不够紧凑的索引结构,后
续不得不通过 OPTIMIZE TABLE(optimize table)来重建表并优化填充页面。
为什么要使用索引?
1. 通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性。
2. 可以大大加快 数据的检索速度(大大减少的检索的数据量), 这也是创建索引的最主要
的原因。
3. 帮助服务器避免排序和临时表
索引创建原则
1.选择唯一性索引
5
唯一性索引的值是唯一的,可以更快速的通过该索引来确定某条记录。例如,学生表中学
号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。如果
使用姓名的话,可能存在同名现象,从而降低查询速度。
2.为经常需要排序、分组和联合操作的字段建立索引
经常需要 ORDER BY、GROUP BY、DISTINCT 和 UNION 等操作的字段,排序操作会浪
费很多时间。如果为其建立索引,可以有效地避免排序操作。
3.为常作为查询条件的字段建立索引
如果某个字段经常用来做查询条件,那么该字段的查询速度会影响整个表的查询速度。因
此,为这样的字段建立索引,可以提高整个表的查询速度。
4.限制索引的数目
索引的数目不是越多越好。每个索引都需要占用磁盘空间,索引越多,需要的磁盘空间就
越大。修改表时,对索引的重构和更新很麻烦。越多的索引,会使更新表变得很浪费时
间。
5.尽量使用数据量少的索引
如果索引的值很长,那么查询的速度会受到影响。例如,对一个 CHAR(100)类型的字段进
行全文检索需要的时间肯定要比对 CHAR(10)类型的字段需要的时间要多。
6.尽量使用前缀来索引
如果索引字段的值很长,最好使用值的前缀来索引。例如,TEXT 和 BLOG 类型的字段,
进行全文检索会很浪费时间。如果只检索字段的前面的若干个字符,这样可以提高检索速
度。
7.删除不再使用或者很少使用的索引
表中的数据被大量更新,或者数据的使用方式被改变后,原有的一些索引可能不再需要。
数据库管理员应当定期找出这些索引,将它们删除,从而减少索引对更新操作的影响。
8 . 最左匹配原则,非常重要的原则。
mysql 会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配,比如 a 1=””
and=”” b=”2” c=”“> 3 and d = 4 如果建立(a,b,c,d)顺序的索引,d 是用不到索引的,如果建
立(a,b,d,c)的索引则都可以用到,a,b,d 的顺序可以任意调整。
剩余33页未读,继续阅读
ask_ai_app
- 粉丝: 18
- 资源: 326
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0