MySQL DATE/Timestamp查询问题排查：时间范围过滤语句错误分析

咱们来拆解下你写的SQL里存在的几个关键问题：

1. 函数转换导致索引失效，性能极差 #

你对ORIGIN_TIMESTAMP列使用DATE_FORMAT()函数后，数据库无法利用该列上已有的索引，只能做全表扫描。如果TRANSACTION_LOG表数据量较大，查询速度会慢到难以接受——这是时间范围查询里的典型反模式。

2. 字符串比较的语法错误 #

你的SQL里日期字符串没有用单引号包裹，比如> " + 2018-01-19T11:11+ "这种写法，数据库会把2018-01-19T11:11当成数学表达式计算（2018减1减19减T...），直接触发语法错误，根本无法执行。

3. 不必要的类型转换风险 #

即使你补了单引号，把时间转成字符串再比较也属于多此一举：原生的时间戳/日期类型本身就支持直接的范围比较，字符串比较虽然在格式正确时看似可行，但本质是文本维度的对比，远不如原生时间类型的对比精准可靠。

正确的写法示例 #

根据ORIGIN_TIMESTAMP的类型，推荐以下两种方案：

情况1：ORIGIN_TIMESTAMP是DATETIME/TIMESTAMP类型

直接用标准时间字符串做范围对比，数据库会自动识别并利用索引：

SELECT * 
FROM TRANSACTION_LOG 
WHERE ORIGIN_TIMESTAMP > '2018-01-19 11:11:00' 
  AND ORIGIN_TIMESTAMP < '2018-04-01 01:01:00';

如果习惯用ISO格式（带T），多数数据库也支持：

SELECT * 
FROM TRANSACTION_LOG 
WHERE ORIGIN_TIMESTAMP > '2018-01-19T11:11:00' 
  AND ORIGIN_TIMESTAMP < '2018-04-01T01:01:00';

情况2：ORIGIN_TIMESTAMP是UNIX时间戳（数字类型）

把查询的时间转成UNIX时间戳再对比，同样能利用索引：

SELECT * 
FROM TRANSACTION_LOG 
WHERE ORIGIN_TIMESTAMP > UNIX_TIMESTAMP('2018-01-19 11:11:00') 
  AND ORIGIN_TIMESTAMP < UNIX_TIMESTAMP('2018-04-01 01:01:00');

内容的提问来源于stack exchange，提问作者user9630712