关于数据库的主从、索引以及存储引擎的核心原理

简介: 数据库的主从、索引以及存储引擎讲解

数据库三范式

一:确保每列的原子性

二:非主键列不存在对主键的部分依赖 (要求每个表只描述一件事情)

三:满足第二范式,并且表中的列不存在对非主键列的传递依赖

数据库主从复制原理

(1):主库 db 的更新事件(update、insert、delete)被写到 binlog

(2):主库创建一个 binlog dump thread 线程,把 binlog 的内容发送到从库

(3):从库创建一个 I/O 线程,读取主库传过来的 binlog 内容并写入到 relay log.

(4):从库还会创建一个 SQL 线程,从 relay log 里面读取内容写入到 slave 的 db.

复制方式分类

(1):异步复制(默认) 主库写入 binlog 日志后即可成功返回客户端,无须等待 binlog 日志传递给从库的过程,但是一旦主库宕机,就有可能出现丢失数据的情况。

(2)半同步复制:( 5.5 版本之后) (安装半同步复制插件)确保从库接收完成主库传递过来的 binlog 内容已经写入到自己的 relay log(传送 log)后才会通知主库上面的等待线程。如果等待超时,则关闭半同步复制,并自动转换为异步复制模式,直到至少有一台从库通知主库已经接收到 binlog 信息为止

存储引擎

(1):Myiasm 是 mysql 默认的存储引擎,不支持数据库事务,行级锁,外键;插入更新需锁表,效率低,查询速度快,Myisam 使用的是非聚集索引

(2):innodb 支持事务,底层为 B + 树实现,适合处理多重并发更新操作,普通 select 都是快照读,快照读不加锁。InnoDb 使用的是聚集索引

聚集索引

(1):聚集索引就是以主键创建的索引

(2):每个表只能有一个聚簇索引,因为一个表中的记录只能以一种物理顺序存放,实际的数据页只能按照一颗 B+ 树进行排序

(3):表记录的排列顺序和与索引的排列顺序一致

(4):聚集索引存储记录是物理上连续存在

(5):聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多

(6):聚簇索引适合排序,非聚簇索引不适合用在排序的场合,因为聚簇索引叶节点本身就是索引和数据按相同顺序放置在一起,索引序即是数据序,数据序即是索引序,所以很快。非聚簇索引叶节点是保留了一个指向数据的指针,索引本身当然是排序的,但是数据并未排序,数据查询的时候需要消耗额外更多的 I/O,所以较慢

(7):更新聚集索引列的代价很高,因为会强制 innodb 将每个被更新的行移动到新的位置

非聚集索引

(1):除了主键以外的索引

(2):聚集索引的叶节点就是数据节点,而非聚簇索引的叶节点仍然是索引节点,并保留一个链接指向对应数据块

(3):聚簇索引适合排序,非聚簇索引不适合用在排序的场合

(4):聚集索引存储记录是物理上连续存在,非聚集索引是逻辑上的连续。

使用聚集索引为什么查询速度会变快?

使用聚簇索引找到包含第一个值的行后,便可以确保包含后续索引值的行在物理相邻

建立聚集索引有什么需要注意的地方吗?

在聚簇索引中不要包含经常修改的列,因为码值修改后,数据行必须移动到新的位置,索引此时会重排,会造成很大的资源浪费

InnoDB 表对主键生成策略是什么样的?

优先使用用户自定义主键作为主键,如果用户没有定义主键,则选取一个 Unique 键作为主键,如果表中连 Unique 键都没有定义的话,则 InnoDB 会为表默认添加一个名为 row_id 隐藏列作为主键。

非聚集索引最多可以有多少个?

每个表你最多可以建立 249 个非聚簇索引。非聚簇索引需要大量的硬盘空间和内存

BTree 与 Hash 索引有什么区别?

(1):BTree 索引可能需要多次运用折半查找来找到对应的数据块 (2):HASH 索引是通过 HASH 函数,计算出 HASH 值,在表中找出对应的数据 (3):大量不同数据等值精确查询,HASH 索引效率通常比 B+TREE 高 (4):HASH 索引不支持模糊查询、范围查询和联合索引中的最左匹配规则,而这些 Btree 索引都支持

数据库索引优缺点

(1):需要查询,排序,分组和联合操作的字段适合建立索引

(2):索引多,数据更新表越慢,尽量使用字段值不重复比例大的字段作为索引,联合索引比多个独立索引效率高

(3):对数据进行频繁查询进建立索引,如果要频繁更改数据不建议使用索引

(4):当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,降低了数据的维护速度。

索引的底层实现是 B + 树,为何不采用红黑树,B 树?

(1):B+Tree 非叶子节点只存储键值信息,降低 B+Tree 的高度,所有叶子节点之间都有一个链指针,数据记录都存放在叶子节点中

(2):红黑树这种结构,h 明显要深的多,效率明显比 B-Tree 差很多

(3):B + 树也存在劣势,由于键会重复出现,因此会占用更多的空间。但是与带来的性能优势相比,空间劣势往往可以接受,因此 B + 树的在数据库中的使用比 B 树更加广泛

索引失效条件

(1):条件是 or,如果还想让 or 条件生效,给 or 每个字段加个索引

(2):like 开头 %

(3):如果列类型是字符串,那一定要在条件中将数据使用引号引用起来,否则不会使用索引

(4):where 中索引列使用了函数或有运算

目录
相关文章
|
3月前
|
存储 关系型数据库 MySQL
MySQL数据库索引的数据结构?
MySQL中默认使用B+tree索引,它是一种多路平衡搜索树,具有树高较低、检索速度快的特点。所有数据存储在叶子节点,非叶子节点仅作索引,且叶子节点形成双向链表,便于区间查询。
140 4
|
4月前
|
存储 算法 关系型数据库
数据库主键与索引详解
本文介绍了主键与索引的核心特性及其区别。主键具有唯一标识、数量限制、存储类型和自动排序等特点,用于确保数据完整性和提升查询效率;而索引通过特殊数据结构(如B+树、哈希)优化查询速度,适用于不同场景。文章分析了主键与索引的优劣、适用场景及工作原理,并对比两者在唯一性、数量限制、功能定位等方面的差异,为数据库设计提供指导。
|
7月前
|
存储 缓存 数据库
数据库索引采用B+树不采用B树的原因?
● B+树更便于遍历:由于B+树的数据都存储在叶子结点中,分支结点均为索引,方便扫库,只需要扫一遍叶子结点即可,但是B树因为其分支结点同样存储着数据,我们要找到具体的数据,需要进行一次中序遍历按序来扫,所以B+树更加适合在区间查询的情况,所以通常B+树用于数据库索引。 ● B+树的磁盘读写代价更低:B+树在内部节点上不包含数据信息,因此在内存页中能够存放更多的key。 数据存放的更加紧密,具有更好的空间局部性。因此访问叶子节点上关联的数据也具有更好的缓存命中率。 ● B+树的查询效率更加稳定:由于非终结点并不是最终指向文件内容的结点,而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条
|
8月前
|
缓存 NoSQL Redis
Redis原理—2.单机数据库的实现
本文概述了Redis数据库的核心结构和操作机制。
Redis原理—2.单机数据库的实现
|
10月前
|
存储 缓存 数据库
数据库索引采用B+树不采用B树的原因?
B+树优化了数据存储和查询效率,数据仅存于叶子节点,便于区间查询和遍历,磁盘读写成本低,查询效率稳定,特别适合数据库索引及范围查询。
138 6
|
11月前
|
存储 缓存 网络安全
南大通用GBase 8s 数据库 RHAC集群基本原理和搭建步骤
南大通用GBase 8s 数据库 RHAC集群基本原理和搭建步骤
|
11月前
|
存储 缓存 数据库
数据库索引采用B+树不采用B树的原因
B+树相较于B树,在数据存储、磁盘读写、查询效率及范围查询方面更具优势。数据仅存于叶子节点,便于高效遍历和区间查询;内部节点不含数据,提高缓存命中率;查询路径固定,效率稳定;特别适合数据库索引使用。
143 1
|
11月前
|
数据库 索引
数据库索引
数据库索引 1、索引:建立在表一列或多列的辅助对象,目的是加快访问表的数据。 2、索引的优点: (1)、创建唯一性索引,可以确保数据的唯一性; (2)、大大加快数据检索速度; (3)、加速表与表之间的连接; (4)、在查询过程中,使用优化隐藏器,提高系统性能。 3、索引的缺点: (1)、创建和维护索引需要耗费时间,随数据量增加而增加; (2)、索引占用物理空间; (3)、对表的数据进行增删改时,索引需要动态维护,降低了数据的维护速度。
168 2
|
1月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
76 3
|
1月前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。

热门文章

最新文章