DATEPART函数作用于索引列会导致全表扫描，应改用时间范围查询替代；可建持久化计算列加索引优化高频日期部分查询，但需注意统计信息更新。
DATEPART 函数直接作用于索引列会导致全表扫描
只要在 WHERE 子句里对索引列调用 DATEPART（比如 DATEPART(YEAR, create_time)），SQL Server 就无法利用该列上的索引做 Seek，大概率退化为 Index Scan 或 Table Scan。本质是：索引里存的是原始 datetime 值，而 DATEPART 强制逐行计算，破坏了 B+Tree 的有序查找能力。
用范围查询替代 DATEPART 提取年/月/日
把“提取某一部分再比较”的逻辑，换成“构造对应时间范围再判断”，让优化器能走索引 Seek。
-
DATEPART(YEAR, order_date) = 2023→ 改成order_date >= '2023-01-01' AND order_date -
DATEPART(MONTH, order_date) = 6→ 改成order_date >= '2023-06-01' AND order_date -
DATEPART(DAY, order_date) = 15→ 不推荐单独按日查（选择性差），如必须，可用CAST(order_date AS DATE) = '2023-06-15'（前提是order_date列有索引，且类型为datetime或datetime2）
注意隐式转换和数据类型对齐
即使你写了范围条件，如果右侧常量类型不匹配，仍会触发隐式转换，间接导致索引失效。
- 错误写法：
order_date >= '2023-01-01'（字符串）→ SQL Server 可能转成datetime，但若列是datetime2，仍有风险 - 稳妥写法：
order_date >= CAST('2023-01-01' AS DATE)或直接用带精度的字面量：order_date >= '2023-01-01T00:00:00' - 检查执行计划中
key是否非 NULL、type是否为seek，而非scan
当必须按日期部分过滤时，考虑计算列 + 索引
如果业务频繁按年、月、周等维度查询，又不愿每次改写 SQL，可建持久化计算列并为其建索引：
ALTER TABLE orders ADD order_year AS DATEPART(YEAR, order_date) PERSISTED; CREATE INDEX IX_orders_order_year ON orders(order_year);
之后查询 WHERE order_year = 2023 就能走索引。但要注意：PERSISTED 会占用额外存储，且该列值随原列自动更新，不可手动修改。
最易被忽略的一点：哪怕你把 DATEPART 换成了范围条件，如果表统计信息过期（比如近期批量导入大量数据后没更新），优化器仍可能误判成本、放弃 Seek。上线前务必确认 UPDATE STATISTICS orders 已执行，或确保数据库启用了 AUTO_UPDATE_STATISTICS。
