MySQL TIMESTAMP 类型加索引时出现的bug

数据库:MySQL,版本:5.1.45

查询语句1:

select id, settlement_begin_time , settlement_end_time  from mkt_vendor_settlement_brief where settlement_begin_time >= ‘2017-09-01 00:00:00.0‘ and settlement_end_time <=  ‘2017-09-30 23:59:59.0‘;

结果:

查询语句2:

select id, settlement_begin_time , settlement_end_time  from mkt_vendor_settlement_brief where settlement_begin_time >= ‘2017-09-01 00:00:00‘ and settlement_end_time <=  ‘2017-09-30 23:59:59.0‘

结果:

对settlement_begin_time 添加了索引,查询语句的区别: 一个有".0"一个没有“.0”

删掉索引后有".0"的也能正常查询。

经调查,这是MySQL的一个bug,在后续版本中已经修复,本人使用mysql5.5进行测试一切正常。

出现此问题时的解决方案:

1.  升级MySQL版本,最有效

2. 曲线救国,Java代码中,预先将Timestamp类型的数据进行格式化,然后以字符串的方式放入查询语句,因为mysql-jdbc调用的  “PreparedStatement” 的setTimestamp方法会加上".0"

时间: 2024-10-27 17:27:41

MySQL TIMESTAMP 类型加索引时出现的bug的相关文章

关于Mac系统中SequelPro工具对于Mysql数值类型nt(M)存值的bug

说问题之前,聊表一下mysql数值类型int.众所周知,mysql数值类型int占四个字节,有符号.无符号整形存储的范围不同,有符号范围-2147483648 - 2127483647,无符号范围是0 - 4294967295(2^32是偶数,这里为什么是奇数,如果不清楚请自行补计算机位运算).Mysql类型关键字后面的括号内指定整数值的显示宽度(例如,INT(4)).该可选显示宽度规定用于显示宽度小于指定的列宽度的值时从左侧填满宽度.显示宽度并不限制可以在列内保存的值的范围,也不限制超过列的指

mysql timestamp类型字段的CURRENT_TIMESTAMP与ON UPDATE CURRENT_TIMESTAMP属性

timestamp有两个属性,分别是CURRENT_TIMESTAMP 和ON UPDATE CURRENT_TIMESTAMP两种,使用情况分别如下: 1.CURRENT_TIMESTAMP 当要向数据库执行insert操作时,如果有个timestamp字段属性设为 CURRENT_TIMESTAMP,则无论这个字段有木有set值都插入当前系统时间 2.ON UPDATE CURRENT_TIMESTAMP 当执行update操作是,并且字段有ON UPDATE CURRENT_TIMESTA

mysql timestamp类型 根据当前时间戳更新

注意到这个是因为一次事故. 一个简单的操作记录表,只记录了一个操作人,操作时间,操作结果. 当时为了演示效果,在生产环境中去修改,创建数据. 一顿操作猛如虎之后发现,所有改过的数据的创建时间都变成了当前时间,演示效果更不好了,还破坏了原本的数据. 经过研究发现,当数据类型是timestamp的时候,多了个根据当前时间更新 也就是下图的这个东西,将创建时间勾选了根据当前时间更新导致的问题. 所以呢.. 如果设置了CURRENT_TIMESTAMP为默认值,勾选了根据当前时间更新,表示每次更新这条数

mysql性能优化之索引优化(转)

作为免费又高效的数据库,mysql基本是首选.良好的安全连接,自带查询解析.sql语句优化,使用读写锁(细化到行).事物隔离和多版本并发控制提高并发,完备的事务日志记录,强大的存储引擎提供高效查询(表记录可达百万级),如果是InnoDB,还可在崩溃后进行完整的恢复,优点非常多.即使有这么多优点,仍依赖人去做点优化,看书后写个总结巩固下,有错请指正. 完整的mysql优化需要很深的功底,大公司甚至有专门写mysql内核的,sql优化攻城狮,mysql服务器的优化,各种参数常量设定,查询语句优化,主

MySQL数据库篇之索引原理与慢查询优化之二

接上篇 7??  正确使用索引 一.索引未命中 并不是说我们创建了索引就一定会加快查询速度,若想利用索引达到预想的提高查询速度的效果, 我们在添加索引时,必须遵循以下问题: #1 范围问题,或者说条件不明确,条件中出现这些符号或关键字:>.>=.<.<=.!= .between...and....like. #2 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*),表示字段不重复的比例,比例越大我们扫描的记录数越少,唯一键的区分度是

MySQL的timestamp类型自动更新问题

今天建了一个表,里面有一个列是timestamp类型,我本意是在数据更新时,这个字段的时间能自动更新.岂知对这个类型的值还不甚了解,导致出错.发现这个字段只是在这行数据建立的时候有值,在更新的却无变化. 查找资料,发现是我建表的语句有问题: 以下是代码片段: CREATE TABLE `test` ( `t1` timestamp NOT NULL default CURRENT_TIMESTAMP, `ww` varchar(5) NOT NULL ) ENGINE=InnoDB DEFAUL

MYSQL中TIMESTAMP类型的默认值

MYSQL中TIMESTAMP类型可以设定默认值,就像其他类型一样. 表: —————————————————————————————————————— t1      CREATE TABLE `t1` (                                                                             `p_c` int(11) NOT NULL,                                              

mysql中datetime和timestamp类型的区别

相同 显示 TIMESTAMP列的显示格式与DATETIME列相同.换句话说,显示宽度固定在19字符,并且格式为YYYY-MM-DD HH:MM:SS. 不同 范围 datetime 以'YYYY-MM-DD HH:MM:SS'格式检索和显示DATETIME值.支持的范围为'1000-01-01 00:00:00'到'9999-12-31 23:59:59'TIMESTAMP值不能早于1970或晚于2037 储存 TIMESTAMP 1.4个字节储存(Time stamp value is st

MySQL的timestamp类型自动更新问题【转】

今天建了一个表,里面有一个列是timestamp类型,我本意是在数据更新时,这个字段的时间能自动更新.岂知对这个类型的值还不甚了解,导致出错.发现这个字段只是在这行数据建立的时候有值,在更新的却无变化. 查找资料,发现是我建表的语句有问题: 以下是代码片段: CREATE TABLE `test` (  `t1` timestamp NOT NULL default CURRENT_TIMESTAMP,  `ww` varchar(5) NOT NULL) ENGINE=MyISAM ; 而实际