我在toad for Oracle中运行以下语句：
select * from hourly_analysis where eff_date like '%JAN-18' fetch next 10 rows only
字符串我添加了fetch 10 rows only，希望它能缩短我的查询运行时间，因为它目前运行了1小时以上。为什么它仍然运行这么长时间，还有什么其他方法可以缩短查询运行时间
fetch 10 rows only
vd2z7a6w1#
我会努力的
select * from hourly_analysis where eff_date >= date '2018-01-01' and eff_date < date '2018-02-01';
字符串并确保eff_date已编入索引。感谢ThorstenKettner告诉 * 由于Oracle错误地命名了他们的日期时间类型DATE，许多用户落入陷阱，将他们的列命名为DATE，而实际上它们是日期时间。因此，尽管名称为eff_date，但该列也可能包含times.*，并且还提供了对WHERE子句的更正！
olqngx592#
数据库仍然需要对表中ALL行的WHERE子句求值，以了解哪些行可能被包括在内，哪些是“NEXT”。考虑到这一点，eff_date like '%JAN-18'表达式与它在检查特定月份时得到的结果一样糟糕。让我们来看看一些真实的的解决方案：1.如果必须使用字符串，请设置值的格式，使元素按从最高有效位（左侧）到最低有效位（右侧）的顺序排列。即，年、月、日、时等。至少这样你就不需要一个前导通配符了，而且如果你很幸运的话，索引可能仍然有用。1.但是不要这样做，使用DateTime系列中的数据类型，而不是字符串。这将改善存储和内存使用，给予您能够访问日期功能，并通常有助于提高整体性能和准确性。这是一笔大买卖。1.一旦您 * 修正了列 *（因为将日期放在varchar列中实际上是一个不完整的架构）以使用日期时间值，请将条件与存储的值匹配，而不是将存储的值与条件匹配。这是什么意思？在这种情况下，您可以不查看数据行中值的月份和年份，而让数据行值保持不变，并使用下列运算式来取得相同的逻辑结果：
WHERE
eff_date like '%JAN-18'
DateTime
where eff_date >= '2008-01-01' and eff_date < '2008-02-01'
字符串这两个比较将快得多，因为不需要逐行转换，并且列上的任何索引都将仍然相关。这就触及了数据库性能的核心。还要注意我是如何在所需范围之后的时刻使用 exclusive 上限的。这样可以避免某些类型的错误，在这些错误中，您可能会将意外的时间组件作为数据的一部分。
2条答案
按热度按时间vd2z7a6w1#
我会努力的
字符串
并确保eff_date已编入索引。
感谢ThorstenKettner告诉 * 由于Oracle错误地命名了他们的日期时间类型DATE，许多用户落入陷阱，将他们的列命名为DATE，而实际上它们是日期时间。因此，尽管名称为eff_date，但该列也可能包含times.*，并且还提供了对WHERE子句的更正！
olqngx592#
数据库仍然需要对表中ALL行的
WHERE子句求值，以了解哪些行可能被包括在内，哪些是“NEXT”。考虑到这一点，eff_date like '%JAN-18'表达式与它在检查特定月份时得到的结果一样糟糕。让我们来看看一些真实的的解决方案：
1.如果必须使用字符串，请设置值的格式，使元素按从最高有效位（左侧）到最低有效位（右侧）的顺序排列。即，年、月、日、时等。至少这样你就不需要一个前导通配符了，而且如果你很幸运的话，索引可能仍然有用。
1.但是不要这样做，使用
DateTime系列中的数据类型，而不是字符串。这将改善存储和内存使用，给予您能够访问日期功能，并通常有助于提高整体性能和准确性。这是一笔大买卖。1.一旦您 * 修正了列 *（因为将日期放在varchar列中实际上是一个不完整的架构）以使用日期时间值，请将条件与存储的值匹配，而不是将存储的值与条件匹配。
这是什么意思？在这种情况下，您可以不查看数据行中值的月份和年份，而让数据行值保持不变，并使用下列运算式来取得相同的逻辑结果：
字符串
这两个比较将快得多，因为不需要逐行转换，并且列上的任何索引都将仍然相关。这就触及了数据库性能的核心。还要注意我是如何在所需范围之后的时刻使用 exclusive 上限的。这样可以避免某些类型的错误，在这些错误中，您可能会将意外的时间组件作为数据的一部分。