我有一个带有SELECT语句的站点，如下所示：
SELECT * FROM MyTable WHERE MyDate >= GETDATE()
我的记录值为6/24/2009 9:00:00 AM到MyDate字段。
当用户在上午9:00:00之前的6/24/2009访问此页面时，将显示此记录。但是当用户在6/24/2009访问此页面时，但在上午9:00:00之后，SELECT不会获得此记录。
如何构建此SELECT语句，并将此时间记录为此记录，直到6/24/2009 12:00:00 PM？
谢谢。
答案 0 :(得分：3)
你真的是指中午12:00吗？那是中午，而不是午夜。听起来你真的想要更像这样的东西：
SELECT *
FROM MyTable
WHERE cast(floor(cast(MyDate as float))+1 as datetime) > getdate()
见这个：
How can I truncate a datetime in SQL Server?
在
答案 1 :(得分：2)
MCardinale，你已经有了答案，但我想提出一条额外的建议。
非常确定你想这样做。 SELECT语句中的每行函数从不能很好地扩展，因为数据库表变得更大（不仅仅是接受答案中的那个，我的意思是任何每行函数）。那是因为他们倾向于破坏DBMS选择正确的执行计划以获得最大速度的能力。
如果你想要一个能够很好地扩展的解决方案，你需要在数据库中存储信息，因为提取速度非常快（基于格言，有些人会说这是真的，表行几乎总是读得很远）比他们写的更频繁。
为此，一个可行的解决方案通常是添加一个完整的新列，它只包含给定日期时间列的日期部分，并使用插入/更新触发器来确保它设置正确。
然后，通过在该新列上建立索引，可以完成对每行日期的查询，而不必担心每行函数的性能。
触发器对性能的影响应该无关紧要，因为插入和更新发生的次数远远少于选择。此解决方案的作用是将转换日期时间的成本转换为插入/更新而不是选择，从而大大降低了累积成本。
这在数据库表中变得明显，一旦设置就不会改变 - 每次读取数据时，当前情况的成本（不必要地）都会发生。在这个答案中描述的情况下，成本完全消失。
当然它需要更多的磁盘空间用于表，但我很少见过磁盘空间作为DBMS的瓶颈 - 它几乎总是原始的CPU咕噜声。
现在我意识到这可能会破坏3NF（因为新列可能不依赖于密钥）但通常会为性能提供便利。我遵循的一般规则是在3NF中实现，如果性能成为问题，则回退到其他规范化形式。
只是一些值得思考的东西 - 享受。
Post Scriptum：如果你真的在你的领域存储一个日期时间，你可能应该避免调用它MyDate。如果它真的是一个日期，列类型是错误的（我的建议在这里变得没有意义）。否则，应将其重命名为更具描述性的内容。跟随你的DBA和代码切割工将永远感激： - ）
答案 2 :(得分：1)
您可以对getdate（）执行日期算术运算，以便查询优化器有机会使用MyDate上的任何索引。
SELECT *
FROM MyTable
WHERE MyDate >= cast(floor(cast(getdate() as float)) as datetime)