Mysql支持的数据类型有哪些

Mysql支持的数据类型有哪些,第1张

Mysql支持的多种数据类型主要有:数值数据类型、日期/时间类型、字符串类型。 

1.整数数据类型及其取值范围:

类型

说明

存储需求(取值范围)

tinyint    很小整数    1字节([0~255]、[-128~127])255=2^8-1127=2^7-1  

smallint    小整数    2字节(0~65535、-32768~32767) 65535=2^16-1  

mediumint    中等    3字节(0~16777215) 16777215=2^24-1  

int(integer)    普通    4字节(0~4294967295) 4294967295=2^32-1  

bigint    大整数    8字节(0~18446744073709551615)18446744073709551615=2^64-1  

浮点数&定点数:

类型名称

说明

存储需求

float    单精度浮点数    4字节  

double    双精度浮点数    8字节  

decimal    压缩的“严格”定点数    M+2字节  

注:定点数以字符串形式存储,对精度要求高时使用decimal较好;尽量避免对浮点数进行减法和比较运算。 

2.时间/日期类型: 

year范围:1901~2155 

time格式:‘HH:MM:SS’(如果省略写,并且没有冒号,则默认最右起2位为秒,再到分,最后到时); 

插入系统当前时间:insert into 表名 values(current_date()),(now()) 

date类型:‘YYYY-MM-DD’; 

datetime(日期+时间):‘YYYY-MM-DD HH:MM:SS’或‘YYYYMMDDHHMMSS’,取值范围:‘1000-01-01 00:00:00’~‘9999-12-31 23:59:59’; 

timestamp格式同datetime,但在存储时需要4个字节(datetime需要8字节),并且以UTC(世界标准时间)进行存储(即timestamp会随设置的时区而变化,而datetime存储的绝不会变化);timestamp的范围:1970-2037。 

 

3.字符串类型: 

text类型:tinytext、text、mediumtext、longtext

类型

范围

tinytext    255=2^8-1  

text    65535=2^16-1  

mediumtext    16777215=2^24-1  

longtext    4294967295=4GB=2^32-1  

 

char的存储需求是定义时指定的固定长度;varchar的存储需求是取决于实际值长度。 

set类型格式:set(’值1’,’值2’…) ——可以有0或者多个值,对于set而言,若插入的值为重复的,则只娶一个。插入的值乱序,则自动按顺序插入排列。插入不正常值,则忽略。 

二进制类型: 

bit(M)——保存位字段值(位字段类型),M表示值的位数; 

eg:select BIN(b+0) from 表名;—–b为列名b+0表示将二进制的结果转换为对应的数字的值,BIN()函数将数字转换为二进制。 

 

blog——-二进制大对象,用来存储可变数量的数据。

数据类型

存储范围(字节)

tinyblog    最多255=2^8-1 字节  

bolg    最多65535=2^16-1 字节  

mediumblog    最多16777215=2^24-1 字节  

longblog    最多4294967295=4GB=2^32-1 字节  

索引是在存储引擎中实现的,也就是说不同的存储引擎,会使用不同的索引。MyISAM和InnoDB存储引擎:只支持BTREE索引,也就是说默认使用BTREE,不能够更换,MySQL5.7中InnoDB可以支持HASH索引;MEMORY/HEAP存储引擎:支持HASH和BTREE索引。索引可划分为单列索引(其中包括普通索引、唯一索引、主键索引)、组合索引、全文索引、空间索引,其中单列索引是一个索引只包含单个列,但一个表中可以有多个单列索引。

MySQL中基本索引类型,没有什么限制,允许在定义索引的列中插入重复值和空值,纯粹为了查询数据更快一点。

索引列中的值必须是唯一的,但是允许为空值,

是一种特殊的唯一索引,不允许有空值。

在表中的多个字段组合上创建的索引,只有在查询条件中使用了这些字段的左边字段时,索引才会被使用,使用组合索引时遵循最左前缀集合。

由id、name和age3个字段构成的索引,索引行中就按id/name/age的顺序存放,索引可以索引下面字段组合(id,name,age)、(id,name)或者(id)。如果要查询的字段不构成索引最左面的前缀,那么就不会是用索引,比如,age或者(name,age)组合就不会使用索引查询

全文索引,只有在MyISAM引擎上才能使用,只能在CHAR,VARCHAR,TEXT类型字段上使用全文索引。全文索引就是在一堆文字中,通过其中的某个关键字等,就能找到该字段所属的记录行,比如有"你是个大牛,神人 ..." 通过大牛,可能就可以找到该条记录。这里说的是可能,因为全文索引的使用涉及了很多细节,我们只需要知道这个大概意思。

只有在MyISAM引擎上才能使用,空间索引是对空间数据类型的字段建立的索引,MySQL中的空间数据类型有四种,GEOMETRY、POINT、LINESTRING、POLYGON。

在创建空间索引时,使用SPATIAL关键字。

创建空间索引的列,必须将其声明为NOT NULL。。

SPATIAL INDEX spatIdx(g)

全值匹配我最爱,最左前缀要遵守;

带头大哥不能死,中间兄弟不能断;

索引列上少计算,范围之后全失效;

Like百分写最右,覆盖索引不写星;

不等空值还有or,索引失效要少用;

VAR引号不可丢,SQL高级也不难!

参考: <u>https://blog.csdn.net/zjy15203167987/article/details/81812370</u>

参考: <u>https://www.jianshu.com/p/d5b2f645d657</u>

如果索引包含满足查询的所有数据,就称为覆盖索引。覆盖索引是一种非常强大的工具,能大大提高查询性能。只需要读取索引而不用读取数据有以下一些优点:

(1) 索引项通常比记录要小,所以MySQL访问更少的数据;

(2) 索引都按值的大小顺序存储,相对于随机访问记录,需要更少的I/O;

(3) 大多数据引擎能更好的缓存索引。比如MyISAM只缓存索引。

(4) 覆盖索引对于InnoDB表尤其有用,因为InnoDB使用聚集索引组织数据,如果二级索引中包含查询所需的数据,就不再需要在聚集索引中查找了。

覆盖索引不能是任何索引,只有B-TREE索引存储相应的值。而且不同的存储引擎实现覆盖索引的方式都不同,并不是所有存储引擎都支持覆盖索引(Memory和Falcon就不支持)。

对于索引覆盖查询(index-covered query),使用EXPLAIN时,可以在Extra一列中看到“Using index”。

产品中有一张图片表,数据量将近100万条,有一条相关的查询语句,由于执行频次较高,想针对此语句进行优化。表结构很简单,主要字段:

user_id 用户ID

picname 图片名称

smallimg 小图名称

一个用户会有多条图片记录,现在有一个根据user_id建立的索引:uid,查询语句也很简单。取得某用户的图片集合

执行查询语句(为了查看真实执行时间,强制不使用缓存)

执行了10次,平均耗时在40ms左右。使用explain进行分析

使用了user_id的索引,并且是const常数查找,表示性能已经很好了

因为这个语句太简单,sql本身没有什么优化空间,就考虑了索引。修改索引结构,建立一个(user_id,picname,smallimg)的联合索引:uid_pic。重新执行10次,平均耗时降到了30ms左右。使用explain进行分析

看到使用的索引变成了刚刚建立的联合索引,并且Extra部分显示使用了'Using Index'

'Using Index'的意思是“覆盖索引”,它是使上面sql性能提升的关键。一个包含查询所需字段的索引称为“覆盖索引”,MySQL只需要通过索引就可以返回查询所需要的数据,而不必在查到索引之后进行回表 *** 作,减少IO,提高了效率。

例如上面的sql,查询条件是user_id,可以使用联合索引,要查询的字段是picname smallimg,这两个字段也在联合索引中,这就实现了“覆盖索引”,可以根据这个联合索引一次性完成查询工作,所以提升了性能

InnoDB存储引擎由于实现了行级锁定,虽然在锁定机制的实现方面带来的性能损耗可能比表级锁定要更高一些,但是在整体并发处理能力方面是要远远优于MyISAM的表级锁定的。当系统并发量较高的时候,InnoDB的整体性能和MyISAM相比就会有比较明显的优势了。但是当我们使用不当的时候,可能会让InnoDB的整体性能表现不仅不比MyISAM高,甚至可能会更差。

建议:

(1)尽可能让所有的数据检索都通过索引来完成,从而避免InnoDB因为无法通过索引键加锁而升级为表级锁定

(2)合理设计索引,让InnoDB在索引键上面加锁的时候尽可能准确,尽可能地缩小锁定范围,避免造成不必要的锁定而影响其他Query的执行

(3)尽可能减少基于范围的数据检索过滤条件,避免因为间隙锁带来的负面影响而锁定了不该锁定的记录

(4)尽量控制事务的大小,减少锁定的资源量和锁定时间长度

(5)在业务环境允许的情况下,尽量使用较低级别的事务隔离,以减少MySQL因为实现事务隔离级别所带来的附加成本。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/7356892.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-04
下一篇 2023-04-04

发表评论

登录后才能评论

评论列表(0条)

保存