存储过程参数必须用datetime2而非datetime，否则因精度和范围差异导致隐式转换使索引失效；日期列在where中不可用函数包裹，需用范围查询替代等值；复合索引中日期字段须置于最左位；动态时间应预先计算边界值。
存储过程参数必须用 datetime2，别用 datetime
用 datetime 声明 @start_date 和 @end_date 是索引失效的高频原因。它精度只有 3.33ms，范围窄（1753–9999），更关键的是：当表中日期列是 datetime2(7)，而参数是 datetime，SQL Server 会把整列隐式转成 datetime 再比——索引直接作废。
实操建议：
- 统一声明为
@start_date datetime2(3)（毫秒级足够，节省空间）或@end_date datetime2(7)（与业务表字段对齐） - 若接收字符串（如
@date_str NVARCHAR(20)），开头就显式转换：SET @start_date = TRY_CONVERT(datetime2(3), @date_str)；失败则RETURN，不依赖隐式行为 - 调用方传
GETDATE()或应用层生成的精确时间戳时，datetime2不会截断溢出
WHERE 条件里别用函数包裹日期列
写成 WHERE CONVERT(date, order_time) = '2024-06-15' 看着方便，但会让 SQL Server 放弃 order_time 上的索引，降级为全表扫描——哪怕只有几万行，延迟也会明显升高。
正确做法是保持列裸露，用范围代替等值：
- 查某一天全部数据：
order_time >= '2024-06-15' 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 ，再对 <code>filtered做GROUP BY CONVERT(date, 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）放最前
动态时间计算要预先固化边界值
像“上月”“上周”这类周期，别在 WHERE 里实时算：WHERE order_time >= DATEADD(MONTH, -1, DATEFROMPARTS(YEAR(GETDATE()), MONTH(GETDATE()), 1)) 这种写法每次执行都重新计算，且难读难维护。
实操建议：
- 在存储过程开头就计算好边界：
DECLARE @month_start datetime2(3) = DATEFROMPARTS(YEAR(GETDATE()), MONTH(GETDATE()), 1)；SET @start_date = DATEADD(MONTH, -1, @month_start) - 确保
@end_date是“查询截止时间点”，例如'2024-06-15T00:00:00'，而不是模糊的“2024-06-15” - 检查执行计划：确认
order_time列出现在 Seek Predicates 里，而不是 Residual Predicate
边界值和类型对齐是硬约束，不是可选项。一旦参数类型、索引顺序、WHERE 写法三者中任一环节松动，性能就会断崖式下跌。
