MySQL 数据库存储类型

数值类型包含： int tinyint bigint float decimal

int 大整型（占 4 个字节的存储空间）

tinyint 微小整型（占 1 个字节的存储空间）

bigint 极大整型（占 8 个字节的存储空间）

float 占4个字节，最多显示7个有效位。常用于成绩。

float(5,2)取值范围：

decimal 最多可以显示 28 个有效位

存储空间计算：整数部分和小数部分分开存储，将 9 的倍数包装成 4 个字节，余数占用的字节数如下：

decimal 的整数位和小数位模9的余数和字节对照表

例如： decimal(19,9)

整数部分：

小数部分：

char 定长：当列中存储的字符串达不到最大长度时，使用空格进行补足。

varchar 变长

char 浪费存储空间，但性能高。 varchar 节约存储空间，但存储性能低。

text / longtext(4G)

数值类型宽度为显示宽度，和占用存储空间大小无关；字符类型的宽度，超过则无法存储：

对于枚举类型的字段，字段值只能在列举的范围内选择。

日期时间类型： date time datetime timestamp

date日期：

time时间：

datetime日期时间：

timestamp 日期时间：

日期时间函数： NOW() CURDATE() CURTIME()

NOW() 返回服务器当前的时间：

CURDATE() 返回当前日期：

CURTIME() 返回当前时间：

插入日期时间：

语法格式：

示例：

查询1天以内的记录：

查询2年前至今年的记录：

mysql的程序一共几十兆。跟其他数据库一样，需要占有多少空间要看数据库内容的大小。

如果想知道MySQL数据库中每个表占用的空间、表记录的行数的话，可以打开MySQL的 information_schema 数据库。在该库中有一个 TABLES 表，这个表主要字段分别是：

TABLE_SCHEMA : 数据库名

TABLE_NAME：表名

ENGINE：所使用的存储引擎

TABLES_ROWS：记录数

DATA_LENGTH：数据大小

INDEX_LENGTH：索引大小

所以要知道一个表占用空间的大小，那就相当于是 数据大小 + 索引大小 即可。

查看 /proc/meminfoTips：“大内存页”也称传统大页、大页内存等有助于 Linux 进行虚拟内存的管理，标准的内存页为 4KB，这里使用“大内存页”最大可以定义 1GB 的页面大小，在系统启动期间可以使用“大内存页”为应用程序预留一部分内存，这部分内存被占用且永远不会被交换出内存，它会一直保留在那里，直到改变配置。（详细介绍请看下面链接官方解释）那么这么大页内存是分配给谁的呢？查询一下：shell>/proc/sys/vm/hugetlb_shm_group27shell>id 27uid=27(mysql) gid=27(mysql) groups=27(mysql)hugetlb_shm_group 文件里填的是指定大页内存使用的用户组 id，这里查看到是 MySQL 组 id，那既然是给 MySQL 的为什么 free 等于 total，并且 mysql 还只有 20 多 G 实际使用内存呢？原来在 MySQL 中还有专门启用大内存页的参数，在 MySQL 大内存页称为 large page。查看 MySQL 配置文件发现配置文件中确实有 large-page 配置，但出于禁用状态。后与业务确认，很早之前确实启用过 mysql 的 large page，不过后面禁用了。排查到这基本就有了结论。结论这套环境之前开启了 20000 的大内存页，每页大小为 2MB，占用了 40G 内存空间，给 MySQL 使用，并且 MySQL 开启了 large page，但后来不使用的时候，只关闭了 MySQL 端的 large page 参数，但没有实际更改主机的关于大内存页的配置，所以导致，实际上主机上的还存在 20000 的大内存页，并且没在使用，这一部分长期空闲，并且其他程序不能使用。所以 MySQL 在使用 20G 内存左右，整个主机内存就饱和了，然后在部分条件下，就触发了 OOM，导致 mysqld 被 kill，但主机上又有 mysqld_safe 守护程序，所以又再次给拉起来，就看到了文章初的偶尔连接不上的现象。

---