首先，你的查询能得到正确结果，但存在性能和潜在逻辑风险，下面详细说明并给出优化方案：

原查询的问题 #

1. 性能低下：你用to_char(cast(message_date as date), 'DD-MM-YYYY')包裹了message_date列做范围过滤，这会导致数据库无法使用message_date上的索引（如果有的话），必须逐行转换后再比较，数据量大时查询速度会很慢。
2. 逻辑隐患：字符串的BETWEEN是按字典序比较的，虽然这次的日期范围（15-01到30-01）刚好字典序和日期顺序一致，但如果遇到跨月/跨年的范围（比如'31-01-2018'到'02-02-2018'），字符串比较会得出错误结果（因为'02-02-2018'的字典序比'31-01-2018'小）。

另外注意：原查询里的message LIKE '%hi%'应该是笔误吧？你的列名是msg_details，建议修正为msg_details LIKE '%hi%'，否则会报错或匹配错误列。

优化后的查询方案 #

直接对TIMESTAMP类型的message_date列做范围过滤，避免函数包裹列，这样能利用索引，同时逻辑更可靠：

SELECT 
    msg_id, 
    msg_details, 
    to_char(cast(message_date as date), 'DD-MM-YYYY') as "DATE"
FROM message
WHERE 
    msg_details LIKE '%hi%'
    AND message_date >= '2018-01-15 00:00:00'
    AND message_date < '2018-01-31 00:00:00';

为什么这样写？ #

• 我们直接用message_date >= 起始日期的零点和message_date < 结束日期的下一天零点，这样能精准覆盖2018-01-15到2018-01-30的所有时间（包括1月30日的23:59:59）。
• 数据库可以直接使用message_date上的索引，查询效率大幅提升。
• 避免了字符串比较的逻辑风险，结果更准确。

如果你的数据库支持DATE类型的直接比较，也可以简化为：

SELECT 
    msg_id, 
    msg_details, 
    to_char(cast(message_date as date), 'DD-MM-YYYY') as "DATE"
FROM message
WHERE 
    msg_details LIKE '%hi%'
    AND cast(message_date as date) BETWEEN '2018-01-15' AND '2018-01-30';

不过这种写法依然会对message_date做转换，部分数据库（比如PostgreSQL）可以利用函数索引，但还是不如直接用TIMESTAMP范围的效率高。

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