sql根据时间查询，对date类型的字段to_char

就是想问下，对date类型的字段to_char 这种情况的时间查询会导致查询结果出问题吗？？目前试了两个时间段的查询没问题，因为之前没这么写过，搜百度都说使用to_char函数可能会造成返回结果不准确的问题

1、to_char一个date就是将时间类型转换为字符类型，字符类型的大小有一定的规则，一些特殊字符可能不同的字符集或不同的比较规则输出的结果可能不同，但在正常的时间格式化上，使用【满】时间格式（所有时间位数填满）是没有问题的，但如果不是满时间规则，就很有可能出错，如：

SELECT to_char( SYSDATE, 'yyyy-MM-d hh24:mi:ss' ) FROM dual WHERE '2022-04-4' > '2022-04-10';

　　这个就会有数据输出，但实际上4号是小于10号的，需求上应该是没有数据输出才对

2、从利用索引的角度上，如果accept_date字段上建有索引，那你注释掉的代码才会利用到索引，而to_char这种方法是不会利用到索引的，除非你建立了to_char( accept_date, 'yyyy-MM-dd hh24:mi:ss')的函数索引

3、从比较效率上看，如果这个字段上没有索引、也没有函数索引或者SQL分析器会利用其他更高效的索引，单从where条件比较上，to_char会对每一行的accept_date作一次to_char运算再进行字符串比较，而to_date只会在SQL解析的时候做一次转换，剩下的每行直接进行数字比较（时间类型比较实际上应该是数字类型的比较），因此从比较效率上看应该是to_date更高效

　　综上，除非你在accept_date上建立了to_char的函数索引，否则使用to_date更快才对

　　另外，如果你习惯使用>=和<=来比较范围（我习惯使用between关键字），建议你使用>= '2022-04-01 00:00:00' and < '2022-04-02 00:00:00'，这样可保证一个时间点在59秒到00秒时间范围内的数据，如：2022-04-01 23:59:59.010000 的不会被技术性遗漏掉

按你的逻辑 这个条件不是更快?

to_char(b.accept_date,'yyyyMMdd')='20220401'