mysql中常见的数据类型

一：MySQL数据类型

MySQL中定义数据字段的类型对你数据库的优化是非常重要的

MySQL支持多种数据类型，大致可以分为三类：数值 日期/时间和字符串

二、数值类型

　1.整数类型

2.浮点数

如果希望保证值比较准确，推荐使用定点数数据类型。MySql中的浮点类型有float，double和real。他们定义方式为：FLOAT(M,D) 、 REAL(M,D) 、 DOUBLE PRECISION(M,D)。

FLOAT和DOUBLE中的M和D的取值默认都为0，即除了最大最小值，不限制位数。允许的值理论上是-1.7976931348623157E+308~-2.2250738585072014E-308、0和2.2250738585072014E-308~1.7976931348623157E+308。M、D范围如下：

（MySql5.7实测，与IEEE标准计算的实际是不同的，下面介绍）：M取值范围为0~255。FLOAT只保证6位有效数字的准确性，所以FLOAT(M,D)中，M<=6时，数字通常是准确的。如果M和D都有明确定义，其超出范围后的处理同decimal。

D取值范围为0~30，同时必须<=M。double只保证16位有效数字的准确性，所以DOUBLE(M,D)中，M<=16时，数字通常是准确的。如果M和D都有明确定义，其超出范围后的处理同decimal。

CHAR值时，在它们的右边填充空格以达到指定的长度。当检索到CHAR值时，尾部的空格被删除掉，所以，我们在存储时字符串右边不能有空格，即使有，查询出来后也会被删除。在存储或检索过程中不进行大小写转换。

三、时间日期类型（5）

该“0”值如下：

请点击输入图片描述

四、各种类型占用的存储

1.数值类型

　

请点击输入图片描述

定点数的比较特殊，而且与具体版本也有关系，此处单独解释：

使用二进制格式将9个十进制(基于10)数压缩为4个字节来表示DECIMAL列值。每个值的整数和分数部分的存储分别确定。每个9位数的倍数需要4个字节，并且“剩余的”位需要4个字节的一部分。下表给出了超出位数的存储需求：

请点击输入图片描述

2.时间日期

请点击输入图片描述

从版本5.6.4开始，存储需求就有所改变，根据精度而定。不确定部分需要的存储如下：

请点击输入图片描述

比如，TIME(0), TIME(2), TIME(4), 和TIME(6) 分别使用3, 4, 5, 6 bytes。　

3.字符串

请点击输入图片描述

4.类型的选择

为了优化存储，在任何情况下均应使用最精确的类型。

例如，如果列的值的范围为从1到99999，若使用整数，则MEDIUMINT UNSIGNED是好的类型。在所有可以表示该列值的类型中，该类型使用的存储最少。

用精度为65位十进制数(基于10)对DECIMAL 列进行所有基本计算(+、-、*、/)。

使用双精度 *** 作对DECIMAL值进行计算。如果准确度不是太重要或如果速度为最高优先级，DOUBLE类型即足够了。为了达到高精度，可以转换到保存在BIGINT中的定点类型。这样可以用64位整数进行所有计算，根据需要将结果转换回浮点值。

5.使用其他数据库的SQL语句

为了使用为其它数据库编写的SQL执行代码，MySQL按照下表所示对列类型进行映射。通过这些映射，可以很容易地从其它数据库引擎将表定义导入到MySQL中：

请点击输入图片描述

今天发现网站有点慢，发现mysql日志中提示mysqld-nt:

Out

of

memory

(Needed

1677720

bytes)，经排查是由于最近调整了mysql的一些参数导致，以为内存大就不怕了，32位系统真心内容利用率很低，据说不超过4G，我们的32G内存真浪费了，以后还是使用win2008

r2或centos系统做服务器吧。废话不多说下面为大家分享下解决方法：

因为mysql版本不同可能配置略有区别，主要就是设置如下参数

key_buffer、key_buffer_size、read_buffer_size、sort_buffer_size记住了有这个参数的就改，没有也不要添加。修改后一般是降低，然后重启mysql服务即可。

核心提示：检查mysqld配置my.conf，着重看key_buffer_size,

max_heap_table_size,

tmp_table_size几个参数，推荐设置key_buffer_size值为max_heap_table_size的1/4.

因为服务器内存而大富余比较多，前些天把my.conf里的好几个参数调得相当大，1G甚至2G，但并不稳定，mysqld报出过几次Out

of

memory

(Needed

xxx

bytes)这样的错误，分析原因时，想到是32位linux系统上的linux不支持PAE，不能使用超过3G以上的内存，所以把改大的几个参数适当改小了点，最大也只有几百M的样子，但还是出现过几次Out

of

memory错误。于是网上多方查询，后来受到公式

key_buffer_size

+

(read_buffer_size

+

sort_buffer_size)*max_connections

的启发，两次检查了key_buffer_size,

max_heap_table_size,

tmp_table_size几个参数，发现这三个值的设置是一样的，竟然都是512M！

于是改小key_buffer_size到128M，重启mysqld接下来5个小时的监测，没有再发生类似错误。

改了这几个参数后，还是有一条是Out

of

memory

,继续检查，发现innodb_buffer_pool_size

=

1512M，于是我改为1000M，再启Mysql居然好了。

注：这台服务器一共了才3G内存:最终大至如下

key_buffer

=

200M

key_buffer_size

=

1294963200

#max_join_size

=

4294967295

max_join_size

=

1294967295

max_allowed_packet

=

1M

#table_open_cache

=

512

table_cache

=

512

sort_buffer_size

=

2294967295

read_buffer_size

=

2147479552

#write_buffer_size

=

4294967295

read_rnd_buffer_size

=

4M

myisam_sort_buffer_size

=

64M

thread_cache_size

=

8

query_cache_size=

16M

php错误Fatal

error:

Out

of

memory

(allocated

262144)

(tried

to

allocate

19456

bytes

php运行一段时候后出现错误：

php错误Fatal

error:

Out

of

memory

(allocated

262144)

(tried

to

allocate

19456

bytes

意思是说：致命错误，超出内存，已经分配allocated

262144，尝试分配19456

字节。

解决方法是修改php.ini，加大memory_limit

刚刚着实吓我一跳，html可以正常访问，php不行，我还以为是受攻击呢。

后来看到www.blogguy.cn

上不去了Fatal

error:

Out

of

memory

(allocated

262144)

(tried

to

allocate

19456

bytes，知道是内存不足导致的，可是vps也连不上去，也看不到到底是谁在占内存，只能进网站后台重启vps，就不知道问题出在哪儿了。记录下来备案！

修改方法

修改php.ini

如下的区域

max_execution_time

=

120

Maximum

execution

time

of

each

script,

in

seconds

max_input_time

=

60

Maximum

amount

of

time

each

script

may

spend

parsing

request

data

memory_limit

=

64M

Maximum

amount

of

memory

a

script

may

consume

(64MB)

根据需要调整。

重启一下apache就可以了。

(1) 10*1024*1024*1024(2)其实长度最好的是（2^n）-1因为计算机是二进制计算的，1 bytes = 8 bit ,一个字节最多可以代表的数据长度是2的8次方 11111111 在计算机中也就是-128到127而varchar类型存储变长字段的字符类型，当存储的字符串长度小于255字节时，其需要1字节的空间，当大于255字节时，需要2字节的空间。使用2 ^ n长度是更好的磁盘或内存块对齐。对齐块更快。今天“块”的大小更大，内存和磁盘足够快，可以忽略对齐，对于非常大的块来说是非常重要的。所以使用（2^n）-1 可以更好的利用磁盘空间和内存，使数据库可以在最大限度内存储更多的数据

---