Incorrect datetime value

  • 时间:
  • 浏览:1
  • 来源:神彩UU直播现场_彩神UU直播现场官方

| Variable_name | Value                                                                                                                         |

+—————+————————————————————————————–+

实在 打上去了no_zero_date和no_zero_in_date,但在参数中还有你类似于 个 参数的处于,于是exit该会话,在查看参数的值依然无效:

+———————+

接着想到mysql中alter table add column运行总要对原表进行临时克隆好友,在副本上进行更改,为什么么让删除原表,再对新表进行重命名。没有报错的原由于什么么让在ddl过程中copy原表,在copy表的过程中发现有表中GMT_CLEANUP的数据为’0000-00-00 00:00:00’,mysql认为该数据是不合法的数据:

| Variable_name | Value                                                                                |

那先 值,这是将sql_mode设为了:TRADITIONAL模式,可是只去除NO_ZERO_IN_DATE,NO_ZERO_DATE是不行的,不到去除TRADITIONAL;

| sql_mode      | STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER |

Query OK, 0 rows affected (0.00 sec)

$perror 1292

| Variable_name | Value                                                                                                                         |

Welcome to the MySQL monitor.  Commands end with ; or \g.

+—————+——————————————————————————————————————————-+

root@DB 07:07:01>show variables like ‘%sql_mode%’;

NO_ZERO_IN_DATE

对于第三个白大问题:为那先 会插入0000-00-00 00:00:00?

参数包包含 no_zero_date,

第三个白大问题0000-00-00 00:00:00是为什么么么被插入到数据库中的,应用有你类似于 需求吗?

错误:1292 SQLSTATE: 2807 (ER_TRUNCATED_WRONG_VALUE)

Records: 106  Duplicates: 0  Warnings: 0

。无效DATETIME、DATE事先TIMESTAMP值被转换为相应类型的“零”值(‘0000-00-00 00:00:00’、’0000-00-00’事先00000000000000)。

今天在开发库上给三个白 表打上去字段事先,发现你造报错:

$mysql -uroot DB

root@DB 07:20:47>show variables like ‘%sql_mode%’;

在严格模式,不接受月或日主次为0的日期。事先使用IGNORE选项,大伙日期插入’0000-00-00’。在非严格模式,都不想 接受该日期,为什么么让生成警告。

简单说sql_mode是设置mysql应该支持那先 sql语法,以及哪种数据验证检查。没有 都不想 更容易地在不同的环境中使用MySQL,并结合其它数据库服务器使用MySQL。都不想 通过用SET [SESSION|GLOBAL] sql_mode=’modes’一句话设置sql_mode变量来更改SQL模式。设置 GLOBAL变量时不到拥有SUPER权限,为什么么让会影响从那时起连接的所有客户端的操作。设置SESSION变量只影响当前的客户端。任何客户端都不想 随时更改我本人的会话 sql_mode值。

root@DB 07:20:48>ALTER TABLE `DB`.`ali_mall_user` ADD COLUMN `status_mode` TINYINT UNSIGNED AFTER `op_invest_id`;

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

+—————+——————————————————————————————————————————-+

1 row in set (0.00 sec)

查找error的信息:

root@DB06:39:56>select GMT_CLEANUP from user where GMT_CLEANUP like ‘%00%’ limit 2

+—————+——————————————————————————————————————————-+

+—————+——————————————————————————————————————————-+

Your MySQL connection id is 23805133

当前数据库的sql_mode包含 :

root@DB06:40:48>show variables like ‘sql_mode’;

| Variable_name | Value                                                                                                                         |

STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER

1 row in set (0.00 sec)

。严格模式允许日期使用“零”主次,类似于’804-04-00’或“零”日期。要想禁止,应在严格模式基础上,启用NO_ZERO_IN_DATE和NO_ZERO_DATE SQL模式。

从上端的sql_mode中都不想 看得人在严格模式(启用STRICT_TRANS_TABLES或STRICT_ALL_TABLES模式)是都不想 插入:0000-00-00 00:00:00’,为什么么让上端还启动了TRADITIONAL,TRADITIONAL中还有NO_ZERO_IN_DATE和NO_ZERO_DATE 模式,所事先期插入了0000-00-00 00:00:00数据,上端有改动了sql_mode,最后由于前面插入插入的数据变为了不合法,可是才会出現上端总总大问题。

+—————+——————————————————————————————————————————-+

+———————+

| sql_mode      | STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER |

+—————+——————————————————————————————————————————-+

| sql_mode      | STRICT_TRANS_TABLES,STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER |

root@DB 06:14:42>ALTER TABLE `DB`.` user` ADD COLUMN `status_mode` TINYINT UNSIGNED AFTER ` test_id`;

Query OK, 106 rows affected (0.66 sec)

| GMT_CLEANUP         |

事先看得人都不想 修改表的特性了,现在mysql允许ddl了。

root@DB 07:07:10>exit

root@DB 07:05:21>set global sql_mode=’STRICT_TRANS_TABLES,STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER’;

Query OK, 0 rows affected (0.00 sec)

[MM-Writable@dev ~]

为那先 会出現你类似于 情况汇报,是总要参数设置的不对,查看得人某些库中sql_mode的参数,都没有设置,唯独你类似于 库中sql_mode设置了,看来不到对sql_mode做详细的了解了:

root@DB 07:07:41>show variables like ‘%sql_mode%’;

1 row in set (0.00 sec)

你类似于 解释不为什么么能 不明白。

+—————+——————————————————————————————————————————-+

root@DB 07:07:43>set global sql_mode=’STRICT_TRANS_TABLES,STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER’;

Bye

+—————+————————————————————————————–+

| 0000-00-00 00:00:00 |

+—————+——————————————————————————————————————————-+

消息:截短了不正确的%s值: ‘%s’

。每个时间类型有三个白 有效值范围和三个白 “零”值,当指定不合法的MySQL不到表示的值时使用“零”值。

在严格模式,从不将 ‘0000-00-00’做为合法日期。你仍或者能 用IGNORE选项插入零日期。在非严格模式,都不想 接受该日期,为什么么让生成警告。

大问题都不想 处置了,改变sql_mode:将no_zero_date和no_zero_in_date打上去:

ERROR 1292 (2807): Incorrect datetime value: ‘0000-00-00 00:00:00’ for column ‘GMT_CLEANUP’ at row 2;

第三个白 大问题:没有为那先 mysql认为0000-00-00 00:00:00是不正确的?

| 0000-00-00 00:00:00 |

1 row in set (0.00 sec)

+—————+——————————————————————————————————————————-+

+—————+————————————————————————————–+

+———————+

| sql_mode      | STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER |

-> ;

对于第三个白 大问题,还是不到回到mysql中对日期时间的定义上,在官方文档上说明MySQL允许将’0000-00-00’保存为“伪日期”(事先不使用NO_ZERO_DATE SQL模式)。这在某些情况汇报下比使用NULL值更方便(为什么么让数据和索引占用的空间更小)。没有接下来,为什么么让看看sql_mode中的参数了;

2 rows in set, 1 warning (0.00 sec)

Server version: 5.1.37-log Source distribution

退出来后,重新登录: