mysql数据库存储类型
Mysql数据库3种存储（MyISAM、MEMORY、InnoDB）引擎区别：
1、Myisam是Mysql的默认存储引擎，当create创建新表时，未指定新表的存储引擎时，默认使用Myisam。MEMORY、InnoDB不是默认存储引擎。
2、InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比Myisam的存储引擎，InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。
Mysql数据库3种存储（MyISAM、MEMORY、InnoDB）区别对比：
1、MyISAM
它不支持事务，也不支持外键，尤其是访问速度快，对事务完整性没有要求或者以SELECT、INSERT为主的应用基本都可以使用这个引擎来创建表。
数据文件和索引文件可以放置在不同的目录，平均分配IO，获取更快的速度。要指定数据文件和索引文件的路径，需要在创建表的时候通过DATA DIRECTORY和INDEX DIRECTORY语句指定，文件路径需要使用绝对路径。
2、MEMORY
memory使用存在内存中的内容来创建表。每个MEMORY表实际对应一个磁盘文件，格式是.frm。MEMORY类型的表访问非常快，因为它到数据是放在内存中的，并且默认使用HASH索引，但是一旦服务器关闭，表中的数据就会丢失，但表还会继续存在。
默认情况下，memory数据表使用散列索引，利用这种索引进行“相等比较”非常快，但是对“范围比较”的速度就慢多了。因此，散列索引值适合使用在"="和"<=>"的操作符中，不适合使用在"<"或">"操作符中，也同样不适合用在order by字句里。如果确实要使用"<"或">"或betwen操作符，可以使用btree索引来加快速度。
存储在MEMORY数据表里的数据行使用的是长度不变的格式，因此加快处理速度，这意味着不能使用BLOB和TEXT这样的长度可变的数据类型。VARCHAR是一种长度可变的类型，但因为它在MySQL内部当作长度固定不变的CHAR类型，所以可以使用。
3、InnoDB
InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比MyISAM的存储引擎，InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。
（1)自动增长列：
InnoDB表的自动增长列可以手工插入，但是插入的如果是空或0，则实际插入到则是自动增长后到值。可以通过"ALTER TABLE...AUTO_INCREMENT=n;"语句强制设置自动增长值的起始值，默认为1，但是该强制到默认值是保存在内存中，数据库重启后该值将会丢失。
可以使用LAST_INSERT_ID()查询当前线程最后插入记录使用的值。如果一次插入多条记录，那么返回的是第一条记录使用的自动增长值。对于InnoDB表，自动增长列必须是索引。如果是组合索引，也必须是组合索引的第一列，但是对于MyISAM表，自动增长列可以是组合索引的其他列，这样插入记录后，自动增长列是按照组合索引到前面几列排序后递增的。
（2）外键约束：
MySQL支持外键的存储引擎只有InnoDB，在创建外键的时候，父表必须有对应的索引，子表在创建外键的时候也会自动创建对应的索引。
Ⅱ mysql 数据库varchar可以存储多少个汉字和多少个数字
首先要确定mysql版本，一般一个汉字2个字节，50即可存25个汉字。
4.0版本以下，varchar(100)，指的是100字节，如果存放UTF8汉字时，只能存33个（每个汉字3字节）
5.0版本以上，varchar(100)，指的是100字符，无论存放的是数字、字母还是UTF8汉字（每个汉字3字节），都可以存放100个。
varchar特点
1、使用比固定长度类型(char)占用更少存储空间(除了使用ROW_FORMAT=FIXED创建的MyISAM表)。
2、使用额外的1-2字节来存储值长度，列长度<=255使用1字节保存，其它情况使用2字节保存。例如varchar(10)会占用11字节存储空间，varchar(500)会占用502字节存储空间。
3、节约空间，所以性能会有帮助。在更新的时候会产生额外的工作。
以上内容参考：网络-varchar
Ⅲ MySQL里存储图片的是什么数据类型
背景
MySQL 一直以来都有 TEXT、BLOB 等类型用来存储图片、视频等大对象信息。比如一张图片，随便一张都 5M 以上。视频也是，随便一部视频就是 2G 以上。
假设用 MySQL 来存放电影视频等信息，一部是 2G，那么存储 1000 部就是 2TB，2TB 也就是 1000 条记录而已，但是对数据库性能来说，不仅仅是看记录数量，更主要的还得看占用磁盘空间大小。空间大了，所有以前的经验啥的都失效了。
所以一般来说存放这类信息，也就是存储他们的存放路径，至于文件本身存放在哪里，那这就不是数据库考虑的范畴了。数据库只关心怎么来的快，怎么来的小。
举例
虽然不推荐 MySQL 这样做，但是也得知道 MySQL 该怎么做才行，做到心里有数。比如下面一张微信图片，大概 5M 的样子。
root@ytt:/var/lib/mysql-files# ls -sihl 微信图片_20190711095019.jpg274501 5.4M -rw-r--r-- 1 root root 5.4M Jul 11 07:17 微信图片_20190711095019.jpg
拷贝 100 份这样的图片来测试
root@ytt:/var/lib/mysql-files# for i in `seq 1 100`; do cp 微信图片_20190711095019.jpg "$i".jpg;done;
root@ytt:/var/lib/mysql-files# ls
100.jpg 17.jpg 25.jpg 33.jpg 41.jpg 4.jpg 58.jpg 66.jpg 74.jpg 82.jpg 90.jpg 99.jpg f8.tsv
10.jpg 18.jpg 26.jpg 34.jpg 42.jpg 50.jpg 59.jpg 67.jpg 75.jpg 83.jpg 91.jpg 9.jpg 微信图片_20190711095019.jpg
1111.jpg 19.jpg 27.jpg 35.jpg 43.jpg 51.jpg 5.jpg 68.jpg 76.jpg 84.jpg 92.jpg f1.tsv
11.jpg 1.jpg 28.jpg 36.jpg 44.jpg 52.jpg 60.jpg 69.jpg 77.jpg 85.jpg 93.jpg f2.tsv
12.jpg 20.jpg 29.jpg 37.jpg 45.jpg 53.jpg 61.jpg 6.jpg 78.jpg 86.jpg 94.jpg f3.tsv
13.jpg 21.jpg 2.jpg 38.jpg 46.jpg 54.jpg 62.jpg 70.jpg 79.jpg 87.jpg 95.jpg f4.tsv
14.jpg 22.jpg 30.jpg 39.jpg 47.jpg 55.jpg 63.jpg 71.jpg 7.jpg 88.jpg 96.jpg f5.tsv
15.jpg 23.jpg 31.jpg 3.jpg 48.jpg 56.jpg 64.jpg 72.jpg 80.jpg 89.jpg 97.jpg f6.tsv
16.jpg 24.jpg 32.jpg 40.jpg 49.jpg 57.jpg 65.jpg 73.jpg 81.jpg 8.jpg 98.jpg f7.tsv
mysql> show create table tt_image1G
*************************** 1. row ***************************
Table: tt_image1
Create Table: CREATE TABLE `tt_image1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`image_file` longblob,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)
mysql> show create table tt_image2G
*************************** 1. row ***************************
Table: tt_image2
Create Table: CREATE TABLE `tt_image2` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`image_file` longtext,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)
mysql> show create table tt_image3G
*************************** 1. row ***************************
Table: tt_image3
Create Table: CREATE TABLE `tt_image3` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`image_file` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)
tt_image1
root@ytt:/var/lib/mysql-files# for i in `seq 1 100`;
do mysql -S /var/run/mysqld/mysqld.sock -e "insert into ytt.tt_image1(image_file)
values (load_file('/var/lib/mysql-files/$i.jpg'))";done;
tt_image2
root@ytt:/var/lib/mysql-files# for i in `seq 1 100`;
do mysql -S /var/run/mysqld/mysqld.sock -e "insert into ytt.tt_image2(image_file)
values (hex(load_file('/var/lib/mysql-files/$i.jpg')))";done;
tt_image3
root@ytt:/var/lib/mysql-files# aa='begin;';for i in `seq 1 100`;
do aa=$aa"insert into ytt.tt_image3(image_file) values
('/var/lib/mysql-files/$i.jpg');";
done;aa=$aa'commit;';mysql -S /var/run/mysqld/mysqld.sock -e "`echo $aa`";
- mysql> select 'tt_image1' as name ,count(*) from tt_image1 union allselect 'tt_image2',count(*) from tt_image2 union all select 'tt_image3', count(*) from tt_image3;+-----------+----------+| name | count(*) |+-----------+----------+| tt_image1 | 100 || tt_image2 | 100 || tt_image3 | 100 |+-----------+----------+3 rows in set (0.00 sec)
- root@ytt:/var/lib/mysql/ytt# ls -silhS tt_image*274603 1.1G -rw-r----- 1 mysql mysql 1.1G Jul 11 07:27 tt_image2.ibd274602 545M -rw-r----- 1 mysql mysql 544M Jul 11 07:26 tt_image1.ibd274605 80K -rw-r----- 1 mysql mysql 112K Jul 11 07:27 tt_image3.ibd
- mysql> select * from tt_image3;+----+----------------------------+| id | image_file |+----+----------------------------+| 1 | /var/lib/mysql-files/1.jpg |+----+----------------------------+...100 rows in set (0.00 sec)
- mysql> DELIMITER $$mysql> USE `ytt`$$mysql> DROP PROCEDURE IF EXISTS `sp_get_image`$$mysql> CREATE DEFINER=`ytt`@`localhost` PROCEDURE `sp_get_image`()mysql> BEGIN DECLARE i,cnt INT DEFAULT 0; SELECT COUNT(*) FROM tt_image1 WHERE 1 INTO cnt; WHILE i < cnt DO SET @stmt = CONCAT('select image_file from tt_image1 limit ',i,',1 into mpfile ''/var/lib/mysql-files/image',i,'.jpg'''); PREPARE s1 FROM @stmt; EXECUTE s1; DROP PREPARE s1; SET i = i + 1; END WHILE; END$$mysql> DELIMITER ;mysql> call sp_get_image;
占用磁盘空间大（这样会带来各种各样的功能与性能问题，比如备份，写入，读取操作等）
使用不易
还是推荐用文件路径来代替实际的文件内容存放
我们建三张表，分别用 LONGBLOB、LONGTEXT 和 VARCHAR 来存储这些图片信息
我们来给三张表插入 100 张图片（插入前，建议把 max_allowed_packet 设置到最大）
检查下三张表记录数
看下文件大小，可以看到实际大小排名，LONGTEXT 字段存储的最大，LONGBLOB 字段缩小到一半，最小的是存储图片路径的表 tt_image3。所以这里从存储空间来看，存放路径最占优势。
那么怎么把图片取出来呢？
tt_image3 肯定是最容易的
tt_image1 直接导出来二进制文件即可，下面我写了个存储过程，导出所有图片。
tt_image2 类似，把 select 语句里 image_file 变为 unhex(image_file) 即可。
总结
这里我举了个用 MySQL 来存放图片的例子，总的来说有以下三点：
Ⅳ “mysql”的存储类型“bit”是什么
Bit称为位数据类型，其数据有两种取值：0和1，长度为1位。在输入0以外的其他值时，系统均把它们当1看待。这种数据类型常作为逻辑变量使用，用来表示真、假或是、否等二值选择。
Ⅳ MYSQL数据库中，常见的数据类型有哪些
MySQL 数据类型细分下来，大概有以下几类：
- 数值，典型代表为 tinyint,int,bigint
- 浮点/定点，典型代表为 float,double,decimal 以及相关的同义词
- 字符串，典型代表为 char,varchar
- 时间日期，典型代表为 date,datetime,time,timestamp
- 二进制，典型代表为 binary,varbinary
- 位类型
- 枚举类型
集合类型
Ⅵ mySQL是什么类型的数据库
mysql（发音为"my
ess
cue
el"，不是"my
sequel"）是一种开放源代码的关系型数据库管理系统（rdbms），mysql数据库系统使用最常用的数据库管理语言--结构化查询语言（sql）进行数据库管理。
由于mysql是开放源代码的，因此任何人都可以在general
public
license的许可下下载并根据个性化的需要对其进行修改。mysql因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下，mysql是管理内容最好的选择。
mysql关系型数据库于1998年1月发行第一个版本。它使用系统核心提供的多线程机制提供完全的多线程运行模式，提供了面向c、c++、eiffel、java、perl、php、python以及tcl等编程语言的编程接口（apis），支持多种字段类型并且提供了完整的操作符支持查询中的select和where操作。
mysql开发组计划于2001年中期公布mysql4.0版本。在这个版本中将有以下新的特性被提供：新的表定义文件格式、高性能的数据复制功能、更加强大的全文搜索功能。在此之后，mysql开发着希望提供安全的数据复制机制、在beos操作系统上的mysql实现以及对延时关键字的定期刷新选项。随着时间的推进，mysql将对ansi
92/ansi
99标准完全兼容。
时至今日
mysql
和
php
的结合绝对是完美.很多大型的网站也用到mysql数据库.mysql的发展前景是非常光明的!
Ⅶ mysql的 存储类型 bit 是
Bit称为位数据类型，其数据有两种取值：0和1，长度为1位。在输入0以外的其他值时，系统均把它们当1看待。这种数据类型常作为逻辑变量使用，用来表示真、假或是、否等二值选择。
Ⅷ mysql 存储金额类型，用什么数据类型比较可靠，一般企业数据用什么数据类型
“数字类”，就是指 DECIMAL 和 NUMERIC，它们是同一种类型。它严格的说不是一种数字类型，因为他们实际上是将数字以字符串形式保存的;他的值的每一位 (包括小数点) 占一个字节的存储空间，因此这种类型耗费空间比较大。但是它的一个突出的优点是小数的位数固定，在运算中不会“失真”，所以比较适合用于“价格”、“金额”这样对精度要求不高但准确度要求非常高的字段。
Ⅸ 关于mysql数据库里面数据类型number的问题
MySQL 数据类型细分下来，大概有以下几类：
数值，典型代表为 tinyint,int,bigint
浮点/定点，典型代表为 float,double,decimal 以及相关的同义词
字符串，典型代表为 char,varchar
时间日期，典型代表为 date,datetime,time,timestamp
二进制，典型代表为 binary,varbinary
位类型
枚举类型
集合类型
大对象，比如 text,blob
json 文档类型
一、数值类型（不是数据类型，别看错了）如果用来存放整数，根据范围的不同，选择不同的类型。
注意：timestamp 代表的时间戳是一个 int32 存储的整数，取值范围为 '1970-01-01 00:00:01.000000' 到 '2038-01-19 03:14:07.999999'；datetime 取值范围为 '1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'。
1. 如果时间有可能超过时间戳范围，优先选择 datetime。2. 如果需要单独获取年份值，比如按照年来分区，按照年来检索等，最好在表中添加一个 year 类型来参与。3. 如果需要单独获取日期或者时间，最好是单独存放，而不是简单的用 datetime 或者 timestamp。后面检索时，再加函数过滤，以免后期增加 SQL 编写带来额外消耗。
建立表 t5，对这些可能需要的字段全部分离开，这样以后写 SQL 语句的时候就很容易了。
当然了，这种情形占用额外的磁盘空间。如果想在易用性与空间占用量大这两点来折中，可以用 MySQL 的虚拟列来实时计算。比如假设 c5 字段不存在，想要得到 c5 的结果。mysql-(ytt/3305)->alter table t5 drop c5, add c5 year generated always as (year(c1)) virtual;Query OK, 1 row affected (2.46 sec)Records: 1 Duplicates: 0 Warnings: 0
五、二进制类型
binary(10)/varbinary(10) 代表的不是字符个数，而是字节数。
行结束符不一样。char 的行结束符是 ，binary 的行结束符是 0x00。
由于是二进制存储，所以字符编码以及排序规则这类就直接无效了。
六、位类型
1. 对于 bit(8) 如果单纯存放 1 位，左边以 0 填充 00000001。2. 查询时可以直接十进制来过滤数据。3. 如果此字段加上索引，MySQL 不会自己做类型转换，只能用二进制来过滤。
创建表 c1, 字段性别定义一个比特位。mysql-(ytt/3305)->create table c1(gender bit(1));Query OK, 0 rows affected (0.02 sec)
mysql-(ytt/3305)->select cast(gender as unsigned) 'f1' from c1;+------+| f1 |+------+| 0 || 1 |+------+2 rows in set (0.00 sec)
过滤数据也一样，二进制或者直接十进制都行。mysql-(ytt/3305)->select conv(gender,16,10) as gender -> from c1 where gender = b'1';+--------+| gender |+--------+| 1|+--------+1 row in set (0.00 sec)mysql-(ytt/3305)->select conv(gender,16,10) as gender -> from c1 where gender = '1';+--------+| gender |+--------+| 1|+--------+1 row in set (0.00 sec)
mysql-(ytt/3305)->create table c2(gender char(0));Query OK, 0 rows affected (0.03 sec)
mysql-(ytt/3305)->select count(*) from c1;+----------+| count(*) |+----------+| 33554432 |+----------+1 row in set (1.37 sec)
mysql-(ytt/3305)->insert into c2 select if(gender = 0,'',null) from c1;Query OK, 33554432 rows affected (2 min 18.80 sec)Records: 33554432 Duplicates: 0 Warnings: 0
两张表的磁盘占用差不多。root@ytt-pc:/var/lib/mysql/3305/ytt# ls -sihl总用量 1.9G4085684 933M -rw-r----- 1 mysql mysql 932M 12月 11 10:16 c1.ibd4082686 917M -rw-r----- 1 mysql mysql 916M 12月 11 10:22 c2.ibd
检索方式稍微有些不同，不过效率也差不多。所以说，字符类型不愧为万能类型。
七、枚举类型
1. 最大占用 2 Byte。2. 最大支持 65535 个不同元素。3. MySQL 后台存储以下标的方式，也就是 tinyint 或者 smallint 的方式，下标从 1 开始。4. 排序时按照下标排序，而不是按照里面元素的数据类型。所以这点要格外注意。
创建表 t7。mysql-(ytt/3305)->create table t7(c1 enum('mysql','oracle','dble','postgresql','mongodb','redis','db2','sql server'));Query OK, 0 rows affected (0.03 sec)
1. 最大占用 8 Byte，int64。2. 内部以二进制位的方式存储，对应的下标如果以十进制来看，就分别为 1,2,4,8，...，pow(2,63)。3. 最大支持 64 个不同的元素，重复元素的插入，取出来直接去重。4. 元素之间可以组合插入，比如下标为 1 和 2 的可以一起插入，直接插入 3 即可。
mysql-(ytt/3305)->create table c7(c1 set('mysql','oracle','dble','postgresql','mongodb','redis','db2','sql server'));Query OK, 0 rows affected (0.02 sec)
mysql-(ytt/3305)->INSERT INTO c7WITH RECURSIVE ytt_number (cnt) AS ( SELECT 1 AS cnt UNION ALL SELECT cnt + 1 FROM ytt_number WHERE cnt < pow(2, 7) )SELECT *FROM ytt_number;Query OK, 128 rows affected (0.01 sec)Records: 128 Duplicates: 0 Warnings: 0
示例 10
mysql-(ytt/3305)->select ytt_sample_data_type(1111,222) 'result';+--------------------------+| result |+--------------------------+| The result is: '246642'. |+--------------------------+1 row in set (0.00 sec)
综上所述，日期这块类型的选择遵循以下原则：
4. 如果有保存毫秒类似的需求，最好是用时间类型自己的特性，不要直接用字符类型来代替。MySQL 内部的类型转换对资源额外的消耗也是需要考虑的。
示例 5
binary 和 varbinary 对应了 char 和 varchar 的二进制存储，相关的特性都一样。不同的有以下几点：
示例 6
来看这个 binary 存取的简单示例，还是之前的变量 @a。
切记！这里要提前计算好 @a 占用的字节数，以防存储溢出。
bit 为 MySQL 里存储比特位的类型，最大支持 64 比特位， 直接以二进制方式存储，一般用来存储状态类的信息。比如，性别，真假等。具有以下特性：
示例 7
其实这样的场景，也可以定义为 char(0)，这也是类似于 bit 非常优化的一种用法。
那现在我给表 c1 简单的造点测试数据。
把 c1 的数据全部插入 c2。
枚举类型，也即 enum。适合提前规划好了所有已经知道的值，且未来最好不要加新值的情形。枚举类型有以下特性：
示例 8
八、集合类型
集合类型 SET 和枚举类似，也是得提前知道有多少个元素。SET 有以下特点：
示例 9
定义表 c7 字段 c1 为 set 类型，包含了 8 个值，也就是下表最大为 pow(2,7)。
插入 1 到 128 的所有组合。
九、数据类型在存储函数中的用法
函数里除了显式声明的变量外，默认 session 变量的数据类型很弱，随着给定值的不同随意转换。
定义一个函数，返回两个给定参数的乘积。定义里有两个变量，一个是 v_tmp 显式定义为 int64，另外一个 @vresult 随着给定值的类型随意变换类型。
简单调用下。
总结
本篇把 MySQL 基本的数据类型做了简单的介绍，并且用了一些容易理解的示例来梳理这些类型。我们在实际场景中，建议选择适合最合适的类型，不建议所有数据类型简单的最大化原则。比如能用 varchar(100)，不用 varchar(1000)。
Ⅹ mysql数据库中有几种数据类型
MySQL数据类型之一字符型
VARCHAR VS CHAR
VARCHAR型和CHAR型数据的这个差别是细微的，但是非常重要。他们都是用来储存字符串长度小于255的字符。
假如你向一个长度为四十个字符的VARCHAR型字段中输入数据Bill Gates。当你以后从这个字段中取出此数据时，你取出的数据其长度为十个字符——字符串Bill Gates的长度。 现在假如你把字符串输入一个长度为四十个字符的CHAR型字段中，那么当你取出数据时，所取出的数据长度将是四十个字符。字符串的后面会被附加多余的空格。
当你建立自己的站点时，你会发现使用VARCHAR型字段要比CHAR型字段方便的多。使用VARCHAR型字段时，你不需要为剪掉你数据中多余的空格而操心。
VARCHAR型字段的另一个突出的好处是它可以比CHAR型字段占用更少的内存和硬盘空间。当你的数据库很大时，这种内存和磁盘空间的节省会变得非常重要
MySQL数据类型之二文本型
TEXT
使用文本型数据，你可以存放超过二十亿个字符的字符串。当你需要存储大串的字符时，应该使用文本型数据。
注意文本型数据没有长度，而上一节中所讲的字符型数据是有长度的。一个文本型字段中的数据通常要么为空，要么很大。
当你从HTML form的多行文本编辑框(TEXTAREA)中收集数据时，你应该把收集的信息存储于文本型字段中。但是，无论何时，只要你能避免使用文本型字段，你就应该不适用它。文本型字段既大且慢，滥用文本型字段会使服务器速度变慢。文本型字段还会吃掉大量的磁盘空间。
一旦你向文本型字段中输入了任何数据(甚至是空值)，就会有2K的空间被自动分配给该数据。除非删除该记录，否则你无法收回这部分存储空间。
MySQL数据类型之三数值型
SQL支持许多种不同的数值型数据。你可以存储整数 INT 、小数 NUMERIC、和钱数 MONEY。
INT VS SMALLINT VS TINYINT
他们的区别只是字符长度：
INT型数据的表数范围是从-2，147，483，647到2，147，483，647的整数
SMALLINT 型数据可以存储从-32768到32768的整数
TINYINT 型的字段只能存储从0到255的整数,不能用来储存负数
通常，为了节省空间，应该尽可能的使用最小的整型数据。一个TINYINT型数据只占用一个字节；一个INT型数据占用四个字节。这看起来似乎差别不大，但是在比较大的表中，字节数的增长是很快的。另一方面，一旦你已经创建了一个字段，要修改它是很困难的。因此，为安全起见，你应该预测以下，一个字段所需要存储的数值最大有可能是多大，然后选择适当的数据类型。
MUNERIC
为了能对字段所存放的数据有更多的控制，你可以使用NUMERIC型数据来同时表示一个数的整数部分和小数部分。NUMERIC型数据使你能表示非常大的数——比INT型数据要大得多。一个NUMERIC型字段可以存储从-1038到1038范围内的数。NUMERIC型数据还使你能表示有小数部分的数。例如，你可以在NUMERIC型字段中存储小数3.14。
当定义一个NUMERIC型字段时，你需要同时指定整数部分的大小和小数部分的大小。如：MUNERIC(23,0)
一个 NUMERIC型数据的整数部分最大只能有28位，小数部分的位数必须小于或等于整数部分的位数，小数部分可以是零。
MONEY VS SMALLMONEY
你可以使用 INT型或NUMERIC型数据来存储钱数。但是，专门有另外两种数据类型用于此目的。如果你希望你的网点能挣很多钱，你可以使用MONEY型数据。如果你的野心不大，你可以使用SMALLMONEY型数据。MONEY型数据可以存储从-922，337，203，685，477.5808到922，337，203，685，477.5807的钱数。如果你需要存储比这还大的金额，你可以使用NUMERIC型数据。
SMALLMONEY型数据只能存储从-214，748.3648到214，748.3647 的钱数。同样，如果可以的话，你应该用SMALLMONEY型来代替MONEY型数据，以节省空间。
MySQL数据类型之四逻辑型
BIT
如果你使用复选框( CHECKBOX)从网页中搜集信息，你可以把此信息存储在BIT型字段中。BIT型字段只能取两个值：0或1。
当心，在你创建好一个表之后，你不能向表中添加 BIT型字段。如果你打算在一个表中包含BIT型字段，你必须在创建表时完成。
MySQL数据类型之五日期型
DATETIME VS SMALLDATETIME
一个 DATETIME型的字段可以存储的日期范围是从1753年1月1日第一毫秒到9999年12月31日最后一毫秒。
如果你不需要覆盖这么大范围的日期和时间，你可以使用SMALLDATETIME型数据。它与DATETIME型数据同样使用，只不过它能表示的日期和时间范围比DATETIME型数据小，而且不如DATETIME型数据精确。一个SMALLDATETIME型的字段能够存储从1900年1月1日到2079年6月6日的日期，它只能精确到秒。
DATETIME型字段在你输入日期和时间之前并不包含实际的数据，认识这一点是重要的。