mysql空值怎么设置 mysql空值和null

可以向mysql数据库中插入空值吗？

可以的，有显式和隐式两种插入空值方式（前提是该字段未设置默认值且允许为空）。

网站建设哪家好，找创新互联公司！专注于网页设计、网站建设、微信开发、微信小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了苏家屯免费建站欢迎大家使用！

例如 t1(id auto_increment primary key,sname varchar(10) not null, address varchar(100))

-- 显式方式向地址字段插入空值

insert into t1 (sname,address) valuse('John',null);

-- 隐式方式向地址字段插入空值

insert into t1 (sname) valuse('John');

mysqlloadnull_value定义

当原始数据中的字段为空且未定义时，MySQL由于某种原因不会使用列默认值(为NULL)，而是使用零。当字段全部丢失时，正确使用NULL。定义：空值(NULL)的长度是NULL，不确定占用了多少存储空间，但是占用存储空间的空字符串('')的长度是0，是不占用空间的通俗的讲：空字符串（''）就像是一个真空转态杯子，什么都没有。

空值（NULL）就像是一个装满空气的杯子，含有东西。二者虽然看起来都是空的、透明的，但是有着本质的区别。

因为空值和null值的定义,但是我们查询时如何正确区分出空值和null值还有很多细节问题应该如何区分NULL值与任何其他值相比都是不正确的,比较结果都为NULL,无法获取到实际意义.如果需要搜索NULL值,不能写成 字段 = NULL,这样写不正确,可以使用 字段 = IS NULL或 字段 = ''空值.聚合函数,如COUNT(),MIN(),SUM()在进行查询时会忽略掉null值在SQL中，NULL值与任何其它值的比较（即使是NULL）永远不会为“真”。包含NULL的表达式总是会导出NULL值，除非在关于操作符的文档中以及表达式的函数中作了其他规定。下述示例中的所有列均返回NULL：如果打算搜索列值为NULL的列，不能使用expr = NULL 如果往这个数据类型的列中插入Null值，则其代表的就是系统的当前时间具auto_increment属性的列如果往这属性的列中插入Null值的话，则系统会插入一个正整数序列而如果在其他数据类型中，如字符型数据的列中插入Null的数据，则其插入的就是一个空值。对此的例外是COUNT(*)，它将计数行而不是单独的列值。例如，下述语句产生两个计数。首先计数表中的行数，其次计数value列中的非NULL值数目可以看出null值参与运算后结果都是null,官方对于布尔运算值的描述是这样的：在MySQL中 0或null代表false,任何其他值都是true(在where测试中数字其他值都代表true)，布尔运算的默认真值是1；

在GROUP BY中根据列值对结果进行分组，如果列的值为NULL，两个NULL值将会被分在一组，下面我们做个测试。如果根据排序条件的列进行排序，那么使用order by desc NULL值将会被最后展示，如果根据ASC排序，那么null值将会首先被展示，空值是一个比较特殊的字段。在MySQL数据库中，在不同的情形下，空值往往代表不同的含义。这是MySQL数据库的一种特性。如在普通的字段中(字符型的数据)，空值就是表示空值。但是如果将一个空值的数据插入到TimesTamp类型的字段中，空值就不一定为空。此时为出现什么情况呢

我先创建了一个表。在这个表中有两个字段：User_id(其数据类型是int)、Date(其数据类型是TimesTamp)。现在往这个表中插入一条记录，其中往Date字段中插入的是一个NULL空值。可是当我们查询时，其结果显示的却是插入记录的当前时间。这是怎么一回事呢?其实这就是在MySQL数据库中执行SQL语句时经常会遇到的一个陷阱：空值不一定为空。在操作时，明明插入的是一个空值的数据，但是最后查询得到的却不是一个空值。

在MySQL数据库中，NULL对于一些特殊类型的列来说，其代表了一种特殊的含义，而不仅仅是一个空值。对于这些特殊类型的列，各位读者主要是要记住两个。一个就是笔者上面举的TimesTamp数据类型。如果往这个数据类型的列中插入Null值，则其代表的就是系统的当前时间。另外一个是具有auto_increment属性的列。如果往这属性的列中插入Null值的话，则系统会插入一个正整数序列。而如果在其他数据类型中，如字符型数据的列中插入Null的数据，则其插入的就是一个空值。

陷阱二：空值不一定等于空字符

在MySQL中，空值(Null)与空字符(’’)相同吗?答案是否定的。

在同一个数据库表中，同时插入一个Null值的数据和一个’’空字符的数据，然后利用Select语句进行查询。显然其显示的结果是不相同的。从这个结果中就可以看出，空值不等于空字符。这就是在MySQL中执行SQL语句遇到的第二个陷阱。在实际工作中，空值数据与空字符往往表示不同的含义。数据库管理员可以根据实际的需要来进行选择。如对于电话号码等字段，可以默认设置为空值(表示根本不知道对方的电话号码)或者设置为空字符(表示后来取消了这个号码)等等。由于他们在数据库中会有不同的表现形式，所以数据库管理员需要区别对待。笔者更加喜欢使用空值，而不是空字符。这主要是因为针对空值这个数据类型有几个比较特殊的运算字符。如果某个字段是空字符，数据库中是利用字段名称来代替。相反，如果插入的是空值，则直接显示的是NULL。这跟其他数据库的显示方式也是不同的。

一是IS NULL 和IS NOT NULL关键字。如果要判断某个字段是否含用空值的数据，需要使用特殊的关键字。其中前者表示这个字段为空，后者表示这个字段为非空。在Select语句的查询条件中这两个关键字非常的有用。如需要查询所有电话号码为空的用户(需要他们补充电话号码信息)，就可以在查询条件中加入is not null关键字。

二是Count等统计函数，在空值上也有特殊的应用。如现在需要统计用户信息表中有电话号码的用户数量，此时就可以使用count函数、同时将电话号码作为参数来使用。因为在统计过程中，这个函数会自动忽略空值的数据。此时统计出来的就是有电话号码的用户信息。如果采用的是空字符的数据，则这个函数会将其统计进去。统计刚才建立的两条记录时，系统统计的结果是1，而不是2。可见系统自动将Null值的数据忽略掉了。

MySQL处理空值时需要注意的两个问题

MySQL数据库是一个基于结构化数据的开源数据库 SQL语句是MySQL数据库中核心语言 不过在MySQL数据库中执行SQL语句 需要小心两个陷阱

陷阱一 空值不一定为空

空值是一个比较特殊的字段 在MySQL数据库中 在不同的情形下 空值往往代表不同的含义 这是MySQL数据库的一种特性 如在普通的字段中(字符型的数据) 空值就是表示空值 但是如果将一个空值的数据插入到TimesTamp类型的字段中 空值就不一定为空 此时为出现什么情况呢(如下图)?

我先创建了一个表 在这个表中有两个字段 User_id(其数据类型是int) Date(其数据类型是TimesTamp) 现在往这个表中插入一条记录 其中往Date字段中插入的是一个NULL空值 可是当我们查询时 其结果显示的却是插入记录的当前时间 这是怎么一回事呢?其实这就是在MySQL数据库中执行SQL语句时经常会遇到的一个陷阱 空值不一定为空 在操作时 明明插入的是一个空值的数据 但是最后查询得到的却不是一个空值

在MySQL数据库中 NULL对于一些特殊类型的列来说 其代表了一种特殊的含义 而不仅仅是一个空值 对于这些特殊类型的列 各位读者主要是要记住两个 一个就是笔者上面举的TimesTamp数据类型 如果往这个数据类型的列中插入Null值 则其代表的就是系统的当前时间 另外一个是具有auto_increment属性的列 如果往这属性的列中插入Null值的话 则系统会插入一个正整数序列 而如果在其他数据类型中 如字符型数据的列中插入Null的数据 则其插入的就是一个空值

陷阱二 空值不一定等于空字符

在MySQL中 空值(Null)与空字符( )相同吗?答案是否定的 请大家先来看下图的演示

在同一个数据库表中 同时插入一个Null值的数据和一个 空字符的数据 然后利用Select语句进行查询 最后显示的结果如上图所示 显然其显示的结果是不相同的 从这个结果中就可以看出 空值不等于空字符 这就是在MySQL中执行SQL语句遇到的第二个陷阱 在实际工作中 空值数据与空字符往往表示不同的含义 数据库管理员可以根据实际的需要来进行选择 如对于电话号码等字段 可以默认设置为空值(表示根本不知道对方的电话号码)或者设置为空字符(表示后来取消了这个号码)等等 由于他们在数据库中会有不同的表现形式 所以数据库管理员需要区别对待 笔者更加喜欢使用空值 而不是空字符 这主要是因为针对空值这个数据类型有几个比较特殊的运算字符 如果某个字段是空字符 数据库中是利用字段名称来代替 相反 如果插入的是空值 则直接显示的是NULL 这跟其他数据库的显示方式也是不同的

一是IS NULL 和IS NOT NULL关键字 如果要判断某个字段是否含用空值的数据 需要使用特殊的关键字 其中前者表示这个字段为空 后者表示这个字段为非空 在Select语句的查询条件中这两个关键字非常的有用 如需要查询所有电话号码为空的用户(需要他们补充电话号码信息) 就可以在查询条件中加入is not null关键字

lishixinzhi/Article/program/MySQL/201311/29455