ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

数据库基础

2022-01-21 14:03:27  阅读:207  来源: 互联网

标签:事务 字节 数据库 基础 回滚 提交 长度 主键


数据库

表该怎么建

主键怎么选?如果不设置主键能否建表,数据库会怎么做

  • 自增序列

  • UUID 随机值

  • 雪花算法

    第一个部分,是 1 个 bit:0,这个是无意义的,为1则为负数。
    第二个部分是 41 个 bit:表示的是时间戳。
    第三个部分是 5 个 bit:表示的是机房 id,10001。
    第四个部分是 5 个 bit:表示的是机器 id,1 1001。
    第五个部分是 12 个 bit:表示的序号,就是某个机房某台机器上这一毫秒内同时生成的 id 的序号,0000 00000000。

    该算法生成19位的long型有序数字,MySQL中用bigint来存储(bigint长度为20位),
    导致主键索引空间会很大,这样二级索引占用空间也会很大(InnoDB引擎),MySQL有限的缓冲区,存储的索引与数据会减少,磁盘IO的概率也会增加

使用InnoDB引擎下应该尽可能的按主键的自增顺序插入,并且尽可能使用单调的增加的聚簇键的值来插入新行,此主键与业务无关,只是用来做主键

如果不设置主键,可以建表,数据库会首先判断表中是否有非空的唯一索引,如果有,则该列为主键,如果没有,则会自动创建一个6字节大小的指针(行号)作为主键,有索引可以通过select _rowid from table查询到主键

image-20210218143607323

Varchar, char,Nvarchar 区别,该怎么用

char是固定长度的,而varchar会根据具体的长度来使用存储空间,另外varchar需要用额外的1-2个字节存储字符串长度。

  • 当字符串长度小于255时,用额外的1个字节来记录长度

  • 当字符串长度大于255时,用额外的2个字节来记录长度

比如char(255)和varchar(255),在存储字符串"hello world"时,char会用一块255个字节的空间放那个11个字符;而varchar就不会用255个,它先计算字符串长度为11,然后再加上一个记录字符串长度的字节,一共用12个字节存储,这样varchar在存储不确定长度的字符串时会大大减少存储空间。

varchar(n):长度为n个字节的可变长度且非Unicode的字符数据。n必须是一个介于1和8,000之间的数值。存储大小为输入数据的字节的实际长度

nvarchar(n):包含n个字符的可变长度Unicode字符数据。n的值必须介于1与4,000之间。字节的存储大小是所输入字符个数的两倍。所输入的数据字符长度可以为零。

  • 文字字段若长度固定,如:身分证号码,就不要用 varchar 或 nvarchar,应该用 char 或 nchar。
  • 支持多语言的站点应考虑使用 Unicode nchar 或 nvarchar 数据类型以尽量减少字符转换问题
  • 文字字段若长度不固定,如:地址,则该用 varchar 或 nvarchar。除了可节省存储空间外,存取硬盘时也会较有效率。

nvarchar适用中文和其他字符,其中N表示Unicode编码,可以解决多语言之间的转换问题

反范式设计

在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,减少了查询时的关联,提高查询效率,因为在数据库的操作中查询的比例要远远大于DML的比例。但是反范式化一定要适度,并且在原本已满足三范式的基础上再做调整的。

也就是在满足三范式的基础上根据业务需求,增加一些冗余字段,方便查找(一张表就能解决,不用连表查询)

流式查询

通过流式查询可以避免一次性查询数据量过大而导致内存溢出

image-20210218174142129

image-20210218174158754

image-20210218174216103

在dao层返回值应为void,在调用方对结果进行处理

如果是返回游标

image-20210218180446999

image-20210218180459761

image-20210218180513551

需要添加@Transactional,否则会报错A Cursor is already closed.

嵌套式事务

Spring的事务传播行为

Propagation属性用来枚举事务的传播行为。所谓事务传播行为就是多个事务方法相互调用时,事务如何在这些方法间传播。默认为REQUIRED。

1、REQUIRED

REQUIRED是常用的事务传播行为,如果当前没有事务,就新建一个事务,如果已经存在一个事务中,加入到这个事务中。

2、REQUIRES_NEW

REQUIRES_NEW表示当前方法必须运行在它自己的事务中。一个新的事务将被启动,如果存在当前事务,在该方法执行期间,当前事务会被挂起(如果一个事务已经存在,则先将这个存在的事务挂起)。

3、NESTED

NESTED表示如果当前已经存在一个事务,那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前事务不存在,那么其行为与REQUIRED一样。嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时,会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚

image-20210219110747759

image-20210219112555427

调用 TestOrderService 的 insertTest1()方法,传播行为NESTED,主事务发生异常,都会回滚,只有子事务发生异常,主事务不会回滚

如果传播行为为REQUIRES_NEW,主事务发生异常,子事务会提交

分布式事务

XA是一个分布式事务协议,由Tuxedo提出。XA中大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如Oracle、MySQL这些商业数据库都实现了XA接口,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

基于XA协议的两阶段提交(2PC)

image-20210219143332254

第一阶段:通知所有需要的数据库准备,数据库执行本地事务(不提交),回复协调者(准备阶段)

第二阶段:提交事务、回滚(执行阶段)

第一阶段全部完成后再进行第二阶段

缺点:性能 因为在准备后每个节点都在占用资源,只有事务协调者通知提交,提交之后才会释放资源

单点故障 事务协调者挂掉,节点不会收到提交或者回滚通知,则会一直无法完成事务

不一致 执行阶段,网络故障可能导致一部分及诶单接受到了消息,则数据会不一致

3PC

三阶段提交协议(3PC)主要是为了解决两阶段提交协议的阻塞问题,2pc存在的问题是当协作者崩溃时,参与者不能做出最后的选择。因此参与者可能在协作者恢复之前保持阻塞。三阶段提交(Three-phase commit),是二阶段提交(2PC)的改进版本。

与两阶段提交不同的是,三阶段提交有两个改动点。

1、 引入超时机制。同时在协调者和参与者中都引入超时机制。
2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

CanCommit PreCommit DoCommit

CanCommit中:

协调者参与者 发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待 参与者 的响应。
参与者 接到CanCommit请求之后,正常情况下,如果其自身认为可以顺利执行事务,则返回Yes响应,并进入预备状态。否则反馈No

TCC

TCC又称补偿事务。其核心思想是:"针对每个操作都要注册一个与其对应的确认和补偿(撤销操作)"。它分为三个操作:

1、Try阶段:主要是对业务系统做检测及资源预留。
2、Confirm阶段:确认执行业务操作。类似commit()
3、Cancel阶段:取消执行业务操作。类似rollback()

try返回成功执行Confirm,返回失败执行Cancel操作

消息事务

消息事务就是基于消息中间件的两阶段提交,本质上是对消息中间件的一种特殊利用,它是将本地事务和发消息放在了一个分布式事务里,保证要么本地操作成功成功并且对外发消息成功,要么两者都失败

img

img

只有A服务执行本地事务成功,B服务才会消费消息,执行其本地事务

发送Half Message 原因:

​ 可以先确认 Brock服务器是否正常 ,如果半消息都发送失败了 那说明Brock挂了。

​ 可以通过半消息来回查事务,如果半消息发送成功后一直没有被二次确认,那么就会回查事务状态

A服务只要执行事务成功,就不管后面的事了,因为RocketMq有重试机制,B服务消费失败会一直推送,如果B服务的事务最终执行失败,那么需要人工处理

标签:事务,字节,数据库,基础,回滚,提交,长度,主键
来源: https://www.cnblogs.com/chen-sc-cn/p/15829962.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有