首页 > 编程知识 正文

mysql数据库类型设计(mysql数据库基本类型)

时间:2023-12-12 12:54:08 阅读:314789 作者:WKCZ

本文目录一览:

北大青鸟java培训:Mysql数据库的设计和优化?

在JAVA开发中数据库的学习也是我们需要了解的,截下来几篇文章都是关于数据库的设计和应用,那么java课程培训机构废话不多说开始学习吧!  数据库的设计  数据库设计是基础,数据库优化是建立在设计基础之上的。

好的数据库一定拥有好的设计。

  数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行环境。

  数据库的三大范式  第一范式1NF:所有的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。

  第二范式2Nf:第二范式在第一范式的基础之上更进一层。

第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。

也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。

  第三范式3Nf:所有字段必须与主键直接相关,而不是间接相关。

也可以理解为字段不要和其他非主键字段相关.  注意:这三个范式尽可能去遵守,不是一定要墨守成规.这只是让我们设计的表的时候,越靠近这些范式,可以使字段尽量的减小冗余.但是有时候也可以根据实际需要小小的违背一下.但是第三范式违反一下还可以接受,但是第一范式别违反.  数据库设计的步骤  需求分析阶段  准确了解与分析用户需求(包括数据与处理)。

是整个设计过程的基础,是最困难、最耗费时间的一步。

  概念结构设计阶段  是整个数据库设计的关键--设计数据库的E-R模型图,确认需求信息的正确和完整  Entity_Relationship---实体之间的关系  一对一  一对多  多对一

MySQL 数据表优化设计(三):CHAR 和 VARCHAR 怎么选?

VARCHAR 和 CHAR 是两种主要的字符串类型,用于存储字符。不幸的是,由于实现的方式依赖于存储引擎,因此很难解释这些字符串在磁盘和内存中如何存储,除了除了常用的 InnoDB 和 MyISAM 外,假设你使用了其他存储引擎,应当仔细阅读存储引擎的文档。

VARCHAR 存储可变长度的字符串,也是最常用的字符数据类型。相比固定长度的类型,VARCHAR 所需的存储空间更小,它会尽可能少地使用存储空间(例如,短的字符串占据的空间)。对于 MyISAM 来说,如果创建表的时候指定了 ROW_FORMAT=FIXED 的话,那么会使用固定的空间存储字段而导致空间浪费。VARCHAR 使用1-2个额外的字节存储字符串的长度:当最大长度低于255字节的时候使用1个字节,如果更多的话就使用2个字节。因此,拉丁字符集的 VARCHAR(10)会使用11个字节的存储空间,而 VARCHAR(1000)则会使用1002个字节的存储空间。

VARCHAR 由于能够节省空间,因此可以改善性能。但是,由于长度可变,当更新数据表的时候数据行的存储空间会变化,这一定程度上会带来额外的开销。如果数据行的长度导致原有的存储位置无法存放,那么不同的存储引擎会做不同的处理。例如 MyISAM 可能产生数据行的碎片,而 InnoDB 需要进行磁盘分页来存放更新后的数据行。

通常,如果最大的列长度远远高于平均长度的话(例如可选的备注字段),使用 VARCHAR 是划算的,同时如果更新的频次很低,那么碎片化也不会是一个问题。需要注意的是,如果使用的是 UTF-8字符集,则实际存储的字节长度是根据字符定的。对于中文,推荐的存储字符集是 utf8mb4。

CHAR 类型的长度是固定的,MySQL 会对每个字段分配足够的存储空间。 存储CHAR 类型值的时候,MySQL 会移除后面多出来的空字符 。值是使用空字符进行对齐以便进行比较。对于短的字符串来说,使用 CHAR 更有优势,而如果所有的值的长度几乎一致的话,就可以使用 CHAR。例如存储用户密码的MD5值时使用 CHAR 就更合适,这是因为 MD5的长度总是固定的。同时,对于字段值经常改变的数据类型来说,CHAR 相比 VARCHAR 也更有优势,因为 CHAR 不会产生碎片。对于很短的数据列,使用 CHAR 比 VARCHAR更高效,例如使用CHAR(1)存储逻辑值的 Y 和 N,这种情况下只需要1个字节,而 VARCHAR 需要2个字节。

对于移除空字符这个特性会感觉奇怪,我们举个例子:

按上面的结果插入数据表后,string2中的前置空格不会移除,但使用 CHAR 类型存储时,string3尾随空格会被移除,使用 SQL 查询结果来检验一下:

得出来的结果如下,可以看到 CHAR 类型的 string3后面的空格被移除了,而 VARCHAR类型的没有。这种情况大多数时候不会有什么问题,实际在应用中也经常会使用 trim 函数移除两端的空字符,但是如果确实需要存储空格的时候,那就需要注意不要选择使用 CHAR 类型:

数据如何存储是由存储引擎决定的,而且存储引擎处理固定长度和可变长度的数据的方式并不相同。Memory 引擎使用固定大小的行,因此它需要分配最大可能的存储空间——即便数据长度是可变的。但是,对于字符串的对齐和空字符截断是由 MySQL 服务端完成的,因此所有存储引擎都是一样的。

与 CHAR 和 VARCHAR 相似的是 BINARY和 VARBINARY,用于存储二进制字节字符,BINARY 的对齐使用字符0的字节值来对齐,并且再获取值的时候不会截断。如果需要使用字符的字节值而不是字符的话,使用 BINARY 会更高效,这是因为比较时,一方面不需要考虑大小写,另一方面是MySQL一次只比较一个字节。

mysql 存储金额类型,用什么数据类型比较可靠,一般企业数据用什么数据类型?

对于游戏币等代币,一般存储为int类型是可行的。问题在于越界,int类型长度为11位。

在存储人民币相关的金额的时候,则只能存储到9长度的人民币,也就是说,最大只能存储999999999,不到10亿的数值,如果业务增长很快的话,就会给自己留下隐患。

Decimal:Decimal为专门为财务相关问题设计的数据类型。

DECIMAL从MySQL 5.1引入,列的声明语法是DECIMAL(M,D)。在MySQL 5.1中,参量的取值范围如下:M是数字的最大数(精度)。其范围为1~65(在较旧的MySQL版本中,允许的范围是1~254),M 的默认 值是10。

D是小数点右侧数字的数目(标度)。其范围是0~30,但不得超过M。说明:float占4个字节,double占8个字节,decimail(M,D)占M+2个字节。

如DECIMAL(5,2) 的最大值为9 9 9 9 . 9 9,因为有7 个字节可用。能够解决数据的范围和精度的问题。

扩展资料

MySQL数据类型DECIMAL用法:

MySQL DECIMAL数据类型用于在数据库中存储精确的数值。我们经常将DECIMAL数据类型用于保留准确精确度的列,例如会计系统中的货币数据。

要定义数据类型为DECIMAL的列,请使用以下语法:column_name  DECIMAL(P,D);

在上面的语法中:

P是表示有效数字数的精度。 P范围为1〜65。

D是表示小数点后的位数。 D的范围是0~30。MySQL要求D小于或等于(=)P。

DECIMAL(P,D)表示列可以存储D位小数的P位数。十进制列的实际范围取决于精度和刻度。

与INT数据类型一样,DECIMAL类型也具有UNSIGNED和ZEROFILL属性。 如果使用UNSIGNED属性,则DECIMAL UNSIGNED的列将不接受负值。

如果使用ZEROFILL,MySQL将把显示值填充到0以显示由列定义指定的宽度。 另外,如果我们对DECIMAL列使用ZERO FILL,MySQL将自动将UNSIGNED属性添加到列。

MYSQL数据库设计数据类型选择需要注意哪些地方

•VARCHAR和CHAR类型,varchar是变长的,需要额外的1-2个字节存储,能节约空间,可能会对性能有帮助。但由于是变长,可能发生碎片,如更新数据;

•使用ENUM代替字符串类型,数据实际存储为整型。

•字符串类型

•要尽可能地避免使用字符串来做标识符,因为它们占用了很多空间并且通常比整数类型要慢。特别注意不要在MYISAM表上使用字符串标识符。MYISAM默认情况下为字符串使用了压缩索引(Packed Index),这使查找更为缓慢。据测试,使用了压缩索引的MYISAM表性能要慢6倍。

•还要特别注意完全‘随机’的字符串,例如由MD5()、SHA1()、UUID()产生的。它们产生的每一个新值都会被任意地保存在很大的空间范围内,这会减慢INSERT及一些SELECT查询。1)它们会减慢INSERT查询,因为插入的值会被随机地放入索引中。这会导致分页、随机磁盘访问及聚集存储引擎上的聚集索引碎片。2)它们会减慢SELECT查询,因为逻辑上相邻的行会分布在磁盘和内存中的各个地方。3)随机值导致缓存对所有类型的查询性能都很差,因为它们会使缓存赖以工作的访问局部性失效。如果整个数据集都变得同样“热”的时候,那么把特定部分的数据缓存到内存中就没有任何的优势了。并且如果工作集不能被装入内存中,缓存就会进行很多刷写的工作,并且会导致很多缓存未命中。

•如果保存UUID值,就应该移除其中的短横线,更好的办法是使用UHEX()把UUID值转化为16字节的数字,并把它保存在BINARY(16)列中。

MYSQL数据库的物理设计都包括哪些内容,怎么设计?

Log File物理结构

从 ib_logfile0和 ib_logfile1这两个文件的物理结构可以看出,在Log Header部分还是有些许差异的, ib_logfile0会多一些额外的信息,主要是checkpoint信息。

并且每个Block的单位是512字节,对应到磁盘每个扇区也是512字节,因此redo log写磁盘是原子写,保证能够写成功,而不像index page一样需要double write来保证安全写入。

我们依次从上到下来看每个Block的结构

Log File Header Block

Log Goup ID,可能会配置多个redo组,每个组对应一个id,当前都是0,占用4字节

Start LSN,这个redo log文件开始日志的lsn,占用8字节

Log File Number,总是为0,占用4字节

Created By,备份程序所占用的字节数,占用32字节

另外在ib_logfile0中会有两个checkpoint block,分别是 LOG_CHECKPOINT_1/ LOG_CHECKPOINT_2,两个记录InnoDB Checkpoint信息的字段,分别从文件头的第二个和第四个block开始记录,并且只在每组log的第一个文件中存在,组内其他文件虽然没有checkpoint相关信息,但是也会预留相应的空间出来。这里为什么有两个checkpoint的呢?原因是设计为交替写入,避免因为介质失败而导致无法找到可用的checkpoint的情况。

Log blocks

请点击输入图片描述

log block结构分为日志头段、日志记录、日志尾部

Block Header,占用12字节

Data部分

Block tailer,占用4字节

Block Header

这个部分是每个Block的头部,主要记录的块的信息

Block Number,表示这是第几个block,占用4字节,是通过LSN计算得来的,占用4字节

Block data len,表示该block中有多少字节已经被使用了,占用2字节

First Rec offet,表示该block中作为第一个新的mtr开始的偏移量,占用2字节

Checkpoint number,表示该log block最后被写入时的检查点的值,占用4字节

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。