sql server存储过程参数应使用datetime2而非datetime，因其精度高、范围广且避免隐式转换导致索引失效；日期字段在复合索引中须置于最左位；where条件中禁用函数包裹索引列，改用范围查询；动态时间计算需预先固化边界值。
SQL Server存储过程参数必须用datetime2而非datetime
用datetime声明@start_date和@end_date是索引失效的常见源头。它精度只有3.33ms，范围窄（1753–9999），且与datetime2列比较时会触发隐式转换——SQL Server被迫把整列转成datetime再比，索引直接作废。
实操建议：
- 统一声明为
@start_date datetime2(3)（毫秒级足够，节省空间）或@end_date datetime2(7)（与业务表字段完全对齐） - 调用方传入
GETDATE()或应用层生成的精确时间戳时，不会被截断 - 如果接收的是字符串（如
@date_str NVARCHAR(20)），开头就显式转换：SET @start_date = TRY_CONVERT(datetime2(3), @date_str)；失败则RETURN，不依赖隐式行为
WHERE里别用CONVERT(date, order_time)这类函数包裹索引列
写成WHERE CONVERT(date, order_time) = '2024-06-09'看着直观，但会让SQL Server放弃order_time上的索引，降级为全表扫描。哪怕表只有几万行，延迟也会明显升高。
正确做法是保持列裸露，用范围代替等值：
- 查某一天全部数据：
order_time >= '2024-06-09' AND order_time （注意是<code>，不是<code>） - 查最近7天：
order_time >= DATEADD(day, -7, GETDATE())，别用BETWEEN——它闭区间特性在含毫秒时容易漏掉23:59:59.9999999 - 若必须按日期聚合，先在CTE里缩小数据集：
WITH filtered AS (SELECT * FROM orders WHERE order_time >= @s AND order_time
复合索引的日期字段必须放最左位
假设常查“某用户在某时间段内的订单”，条件是WHERE user_id = @uid AND order_time BETWEEN @s AND @e，但索引建成了IX_user_time ON orders (user_id, order_time)——这等于白建。SQL Server只能用user_id做等值查找，再对匹配到的所有行逐个检查order_time，无法跳过无关用户的数据。
必须把高频筛选的日期字段放在索引最左侧：
- 推荐建法：
CREATE INDEX IX_order_time_user ON orders (order_time, user_id) - 如果查询还带状态过滤（如
status IN ('paid', 'shipped')），可扩展为(order_time, status, user_id)，但别把低选择性字段（如status）放最前 - 执行计划里确认
order_time出现在Seek Predicates中，而不是Residual Predicate
动态时间计算要避开GETDATE()在WHERE里的重复调用
在存储过程中写WHERE order_time >= DATEADD(day, -30, GETDATE())看似没问题，但GETDATE()是非确定性函数，SQL Server可能在每行都重新计算一次，尤其在大表上影响计划稳定性。
更可控的做法是提前算好边界值：
- 在存储过程开头就固化：
DECLARE @cutoff datetime2(3) = DATEADD(day, -30, GETDATE()) - WHERE里直接用
order_time >= @cutoff，避免函数在运行时反复求值 - 若需排除今天（比如“过去30天不含今天”），用
DATEADD(day, -30, CAST(GETDATE() AS date))，先转成date再加减，避免时分秒干扰
日期范围筛选真正难的不是写法，而是类型对齐、索引可见性和边界语义的一致性——三者只要一个没对齐，性能就可能从毫秒掉到秒级。
