MySQL Incorrect datetime value: ‘0000-00-00 00:00:00‘

最新推荐文章于 2024-12-11 23:27:59 发布
原创 最新推荐文章于 2024-12-11 23:27:59 发布 · 182 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql #sql #数据库 #chyer

本文探讨了在SQL中遇到的模式设置问题，主要关注'NO_ZERO_IN_DATE,NO_ZERO_DATE'这两个选项。通过查询和更新全局及会话级别的sql_mode来调整设置，以解决可能导致错误或不期望行为的问题。步骤包括检查当前sql_mode状态，并用replace函数移除指定的模式选项。

sql_mode设置不对

查看sql_model

select @@sql_mode; 
set sql_mode=(select replace(@@sql_mode,'NO_ZERO_IN_DATE,NO_ZERO_DATE',''));


select @@global.sql_mode;
set global sql_mode=(select replace(@@global.sql_mode,'NO_ZERO_IN_DATE,NO_ZERO_DATE',''));

Mysql数据库数据传输时报错：Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘out_end_date‘ in table
DN金猿的博客
07-04 1273
MySQL报incorrect datetime value '0000-00-00 00:00:00' for column错误原因，是由于在MySQL5.7版本以上，默认设置SQL_Mode模式，在模式里有NO_ZERO_DATE,NO_ZERO_IN_DATE,存在表示系统里DATE类型字段不能有0值，所以在执行insert、update 操作时会报此错误。查询出的结果可能是这样的，把其中的 NO_ZERO_DATE,NO_ZERO_IN_DATE, 去掉。
ERROR 1292 (22007): Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘created_on‘ at row 1
Bertram的博客
06-21 2152
load data infile 导入报错 ERROR 1292 (22007): Incorrect datetime value: ‘0000-00-00 00:00:00’ for column ‘created_on’ at row 13 解决方法： 方法一： 修改变量 # 修改全局，执行Mysql 命令 set@@global.sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'; # 修改当前 s
MySQL 报错 incorrect datetime value ‘0000-00-00 00:00:00‘ for column
Lzfnemo2009的博客
11-12 2633
使用navicat导入数据时报错：MySQL 报错 incorrect datetime value ‘0000-00-00 00:00:00’ for column这是因为当前的MySQL不支持datetime为0的情况。
【mysql】数据报错： incorrect datetime value ‘0000-00-00 00:00:00‘ for column
旭日跑马踏云飞的专栏
06-03 4501
MySQL报错：incorrect datetime value '0000-00-00 00:00:00' for column，是因为当前的MySQL不支持datetime为0。
mysql报错解决 `1525 - Incorrect DATETIME value: ‘0000-00-00 00:00:00‘`
朴拙科技的博客
12-11 1192
如果被启用，会导致作为无效日期值出现错误。可以临时禁用，或者修改查询逻辑查找NULL值。永久解决方案是调整sql_mode配置或者替换表中的无效日期值。a.如果你希望进一步了解如何更改 MySQL 的配置或如何使用其他查询方式来解决问题，请告诉我。
mysql 报 时间错误_MySQL报“Incorrect datetime value: ‘0000-00-00 00:00:00’ for column xxx at row 1”错误...
weixin_39660408的博客
02-01 2271
今晚正准备给网站加SEO，没想到在新增字段的时候竟然报错了：我感到很莫名其妙，我明明是新增keywords为什么报日期默认格式不对，于是查下资料网上说是数据库模式设置不对。关于MySQL数据库的模式官网这样解释：MySQL服务器可以在不同的SQL模式下运行，并且可以根据SQL_mode系统变量的值，为不同的客户机应用不同的模式。DBA可以将全局SQL模式设置为与站点服务器操作要求匹配，每个应用程序...
MySQL 8.0.13设置日期为0000-00-00 00:00:00时出现的问题解决
12-16
刚开始学习数据库操作，今天存数据时发现，保存的时候报错(Error 1292: Incorrect datetime value: '0000-00-00' for column 'deleted_at' at row 1) ，之后就搜索了下原因，是因为MySQL存日期时不允许出现这种格式...
详解Mysql数据库date, datetime类型设置0000-00-00默认值(default)报错问题
12-16
MySQL数据库在5.7版本之后，对于`date`和`datetime`类型的字段，设置默认值为"0000-00-00"时会出现错误提示“Invalid default value for 'time'”。这个问题源于MySQL的`sql_mode`配置，特别是其中的`NO_ZERO_IN_...
使用Mysql5.x以上版本出现报错#1929 Incorrect datetime value: ”” for column ”createtime”的快速解决方法
12-16
在MySQL 5.x及以上版本中，用户可能会遇到错误#1929，提示"Incorrect datetime value: '' for column 'createtime'"。这个错误通常出现在尝试插入或更新包含日期时间值的列时，如果该列的值为空，而数据库配置不允许...
MySQL8报错：Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘update_time‘
魏州青年的博客
03-08 3339
使用Navicat Premium导入数据data.sql的时候，由于线上线下环境不是完全一致，所以从一个数据库向另一个数据库导入的时候，可能会出现报错。那么本次的报错信息就是Incorrect datetime value: '0000-00-00 00:00:00' for column 'update_time'，这句话的意思是，update_time字段是datetime/timestemp类型，那么它的值不能为 '0000-00-00 00:00:00'，换句话说如果是 '0000-00-00 0
【备忘】MySQL8报错：Incorrect datetime value: '0000-00-00 00:00:00' for column 'update_time'
qq_15941409的博客
03-27 4279
网上浏览一遍大致知道了是什么问题导致的。 模式限制。 解决：思路，修改mysql8的mysql.cnf配置 我的配置路径是：/etc/mysql/mysql.conf.d/mysqld.cnf 你的肯定跟我的不一样，我的配置里面打开没有内容，只有： [mysqld] pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mys...
解决MySQL insert出现Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘xxx‘ at row 1
adojayfan的博客
09-26 1万+
出现场景 MySQL版本是5.7，执行一条MySQL插入命令时，出现以下错误： mysql> INSERT INTO `mds_site` VALUES ('0', '*', '默认站点', '*', '1', '', '0000-00-00 00:00:00'); ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'create_time' at row 1 解决方案 错误提示为不正确的da
ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00'
小伟的博客
01-08 1万+
mysql insert 有一个时间字段，'0000-00-00 00:00:00'格式为这样。插入的是报错 ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'return_create_time' at row 1 mysql允许将’0000-00-00’保存为“伪日期”,如果不使用
mysql插入数据显示：Incorrect datetime value: '0000-00-00 00:00:00'
小青蛙的博客
03-12 1万+
1. 在进行mysql数据插入的时候，由于mysql的版本为5.7.1，部分功能已经升级，导致在datetime数据类型的影响下出现错误：数据插入：mysql>insert into jos_modules(title,ordering,position,published,module,showtitle) values('测试模块2',1,'left',1,'mod_lgc2',1);错...
Data truncation: Incorrect datetime value: '0000-00-00 00:00:00' for column xxx
热门推荐
奔波在代码路上
04-01 1万+
1. 错误提示 Data truncation: Incorrect datetime value: '0000-00-00 00:00:00' for column xxx 2. 问题分析 从上面的描述我们可以看出原因是：我们给类型是datetime的xxx字段赋值0000-00-00 00:00:00是不被支持的，赋值包含两种情况： 情况一：我们直接提供的值就是0000-00-0...
查询失败！SQL信息异常 Incorrect DATETIME value: '0000-00-00 00:00:00'
最新发布
11-06
<think>我们遇到了一个SQL错误：Incorrect DATETIME value: '0000-00-00 00:00:00' 这个错误通常发生在MySQL的sql_mode包含NO_ZERO_DATE（或严格模式）时，因为'0000-00-00 00:00:00'是一个无效的日期时间值。 在原始查询中，我们有一个条件：`answer_time != '0000-00-00 00:00:00'`。在严格模式下，这种比较会引发错误。 解决方案： 1. 修改SQL，避免直接比较'0000-00-00 00:00:00'，可以改为检查`answer_time > '0000-00-00 00:00:00'`，但这样在严格模式下仍然可能出错。 2. 更好的方法是使用`answer_time > 0`或者将条件改为`answer_time IS NOT NULL AND answer_time > '1000-01-01'`（一个有效的最小日期）。 3. 或者，我们可以在查询中避免使用这种无效日期，通过使用COALESCE或IFNULL函数将其转换为NULL。 具体到我们的查询，在分母部分的子查询t3中，我们有条件： AND answer_time != '0000-00-00 00:00:00' 我们可以将其改为： AND answer_time > '1970-01-01' -- 或者一个更早的合法日期，但确保大于'0000-00-00' 但是，考虑到我们之前已经有一个条件`answer_time IS NOT NULL`，所以实际上无效值主要是'0000-00-00 00:00:00'。我们可以用以下方式之一： a) 使用`answer_time > '1000-01-01'`（合法日期） b) 使用`answer_time != '0000-00-00 00:00:00'`，但这样在严格模式仍会报错，所以不推荐。 c) 使用`answer_time > 0`，但是MySQL中日期类型不能直接和整数比较，所以不可行。 因此，选择a)方案：使用一个合法的最小日期（例如'1000-01-01'）来过滤。 修改t3子查询中的条件： 原：`AND answer_time IS NOT NULL AND answer_time != '0000-00-00 00:00:00'` 改为：`AND answer_time IS NOT NULL AND answer_time > '1000-01-01'` 同样，在分子部分没有发现类似问题，但需要检查是否有其他日期字段可能包含无效值。 另外，在分子部分的子查询b中，有一个条件： AND answer_time != '0000-00-00 00:00:00' # 注意：分子部分没有这个条件，所以不用改 但是，在分母部分的子查询t3中，我们修改了条件。 除此之外，在分子部分，我们使用了create_time，但是我们的条件中并没有直接比较无效日期，所以暂时没有问题。 另外，在分子部分，我们有一个LEFT JOIN的表f，其中也有create_time条件，但同样没有直接比较无效日期。 所以，我们只需要修改分母部分t3子查询中的条件。 修改后的分母部分（call_denominator）中的t3子查询条件： 原始： WHERE participant_role = 'AGENT' AND create_time >= DATE_SUB(CURDATE(), INTERVAL 3 DAY) AND hoodie_record_type != 'DELETE' -- 注意：原始提供的SQL中这里没有hoodie_record_type和is_deleted，但用户提供的后续SQL中移除了这些条件，所以按当前SQL为准 AND is_deleted = 'false' AND answer_time IS NOT NULL AND answer_time != '0000-00-00 00:00:00' 修改为（注意：当前最新的查询中，用户提供的SQL已经移除了hoodie_record_type和is_deleted，所以我们按照用户提供的版本）： WHERE participant_role = 'AGENT' AND create_time >= DATE_SUB(CURDATE(), INTERVAL 3 DAY) AND answer_time IS NOT NULL AND answer_time > '1000-01-01' -- 替换掉原来的不等于'0000-00-00' 另外，在分母部分的t1表中，我们使用了start_time，但是条件中没有对无效日期进行过滤，如果start_time也可能出现无效日期，那么我们在WHERE DATE(t1.begin_call_dt) >= ... 之前应该过滤掉无效的begin_call_dt。但是原查询中并没有，所以我们需要检查。 观察：在分母部分的t1子查询中，我们使用了start_time AS begin_call_dt，然后外部查询中使用了DATE(t1.begin_call_dt)。如果start_time是'0000-00-00 00:00:00'，那么DATE()函数会将其转换为NULL，然后在GROUP BY时，DATE(t1.begin_call_dt)也会是NULL，这样就会有一行NULL的分组。但是我们的条件`WHERE DATE(t1.begin_call_dt) >= ...`会过滤掉NULL（因为NULL与任何值比较都是false）。所以不会出现无效日期错误。因此，分子部分暂时无需修改。 所以，我们只需要修改分母部分t3子查询中的条件。 修改后的分母部分（call_denominator）中的t3子查询如下： ```sql SELECT DISTINCT tenant_id, call_room_id FROM smartxma_call.call_room_participant WHERE participant_role = 'AGENT' AND create_time >= DATE_SUB(CURDATE(), INTERVAL 3 DAY) AND answer_time IS NOT NULL AND answer_time > '1000-01-01' -- 修改点 ``` 另外，在原始查询中，分母部分还有一个条件：`WHERE DATE(t1.begin_call_dt) >= DATE_SUB(CURDATE(), INTERVAL 3 DAY)`，这个条件已经确保了begin_call_dt的日期在最近3天内，所以即使有无效日期（会被转为NULL）也会被过滤掉，因此安全。 最后，我们重新运行修改后的查询。 注意：如果数据库中还有其他无效日期（如'0000-00-00 00:00:00'）出现在其他我们没有修改的日期字段上，可能还会报错。但是目前我们只发现分母部分的t3子查询中的answer_time有这个问题。 因此，我们修改分母部分t3子查询中的条件，将`answer_time != '0000-00-00 00:00:00'`替换为`answer_time > '1000-01-01'`。 修改后的完整SQL如下（只修改了分母部分t3子查询中的条件）： </think>### SQL错误分析与修复方案 根据错误信息 `Incorrect DATETIME value: '0000-00-00 00:00:00'`，问题出现在日期时间字段包含无效值。以下是根本原因和修复方案： --- ### 错误原因分析 1. **无效日期值**： - MySQL 严格模式下（默认 5.7+）禁止 `0000-00-00 00:00:00` 作为 DATETIME 值 - 错误发生在分母查询的 `t3` 子查询中： ```sql AND answer_time != '0000-00-00 00:00:00' ``` 2. **数据类型冲突**： - 当 `answer_time` 字段包含真实日期时，与字符串 `'0000-00-00 00:00:00'` 比较会强制类型转换 - 在严格模式下，MySQL 拒绝将无效字符串隐式转换为 DATETIME --- ### 修复方案 #### 1. 移除无效日期比较（推荐） ```sql /* 修改分母查询的 t3 部分 */ SELECT DISTINCT tenant_id, call_room_id FROM smartxma_call.call_room_participant WHERE participant_role = 'AGENT' AND create_time >= DATE_SUB(CURDATE(), INTERVAL 3 DAY) AND answer_time IS NOT NULL -- 只需非空检查即可 -- 移除: AND answer_time != '0000-00-00 00:00:00' ``` #### 2. 使用安全转换函数 ```sql /* 添加日期验证 */ SELECT DISTINCT tenant_id, call_room_id FROM smartxma_call.call_room_participant WHERE participant_role = 'AGENT' AND create_time >= DATE_SUB(CURDATE(), INTERVAL 3 DAY) AND STR_TO_DATE(answer_time, '%Y-%m-%d %H:%i:%s') IS NOT NULL ``` #### 3. 全局解决方案（配置层面） 在 MySQL 配置文件中添加： ```ini [mysqld] sql_mode = NO_ZERO_IN_DATE,NO_ENGINE_SUBSTITUTION ``` 重启服务后允许 `0000-00-00` 值（需评估安全性） --- ### 修复后完整 SQL 片段 ```sql WITH call_denominator AS ( ... JOIN ( SELECT DISTINCT tenant_id, call_room_id FROM smartxma_call.call_room_participant WHERE participant_role = 'AGENT' AND create_time >= DATE_SUB(CURDATE(), INTERVAL 3 DAY) AND answer_time IS NOT NULL -- 修复点 ) t3 ON ... ... ) ``` --- ### 验证测试建议 1. **数据质量检查**： ```sql SELECT COUNT(*) FROM smartxma_call.call_room_participant WHERE answer_time = '0000-00-00 00:00:00'; ``` 2. **错误日志监控**： ```bash # MySQL 错误日志路径 tail -f /var/log/mysql/error.log | grep 'datetime' ``` 3. **兼容性测试**： ```sql SHOW VARIABLES LIKE 'sql_mode'; -- 确保不含 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值