嘿，我来帮你搞定这个索引优化的问题！核心目标就是让你的筛选条件能直接命中索引列，避免让SQL引擎做无法利用索引的计算。先结合你现有的两个索引，给你针对性的改写方案：

先明确核心原则 #

不要在timeutc列上做任何函数运算（比如DATEADD(day, -30, timeutc) <= RegisteredUtc），这种写法会让索引直接失效——因为SQL需要逐行计算timeutc的偏移值，没法直接用索引的有序性做范围查找。正确的做法是预先计算出每个公司的30天截止时间，再用这个固定值去匹配timeutc列。

针对第一个索引：(eventtype, timeutc) INCLUDE (companyid) #

这个索引的列顺序非常适合你的需求：首列是等值筛选的eventtype，次列是范围筛选的timeutc，完全符合B树索引的高效使用规则。改写后的查询如下：

-- 先计算每个公司的30天截止时间
WITH CompanyCutoffs AS (
    SELECT 
        companyid,
        DATEADD(day, 30, RegisteredUtc) AS event_cutoff_time
    FROM Companies
)
SELECT e.* -- 尽量只选索引包含的列，进一步提升效率
FROM CompanyCutoffs c
JOIN Events e
    ON e.companyid = c.companyid
    AND e.eventtype = '目标事件类型' -- 先匹配索引首列的等值条件
    AND e.timeutc <= c.event_cutoff_time -- 再用索引次列做范围筛选

为什么这样能利用索引？

SQL会先通过eventtype的等值条件快速定位到索引的对应分支，再在这个分支里用timeutc <= 固定值做范围扫描，直接命中索引的有序结构，避免全表或全索引扫描。而且因为索引包含了companyid，连表回查都可以省去，直接返回结果。

针对第二个索引：(eventtype) INCLUDE (companyid, timeutc) #

这个索引的首列是eventtype，但timeutc是包含列而非索引键列，效率会比第一个索引稍低，但依然可以优化查询：

WITH CompanyCutoffs AS (
    SELECT 
        companyid,
        DATEADD(day, 30, RegisteredUtc) AS event_cutoff_time
    FROM Companies
)
SELECT e.*
FROM CompanyCutoffs c
JOIN Events e
    ON e.companyid = c.companyid
    AND e.eventtype = '目标事件类型' -- 先匹配索引首列
WHERE e.timeutc <= c.event_cutoff_time -- 利用包含列做过滤

为什么这样能利用索引？

SQL会先通过eventtype筛选出所有匹配的行（利用索引），然后通过包含的companyid关联到公司的截止时间，最后用包含的timeutc做过滤。虽然timeutc不是索引键列，但至少避免了全表扫描，而且如果你的eventtype筛选能过滤掉大部分数据，效率依然不错。

额外验证技巧 #

写完查询后，记得查看执行计划：如果看到**“索引查找（非聚集）”**，说明索引被正确利用了；如果是“索引扫描”或“表扫描”，可能需要检查eventtype的筛选是否足够精准，或者调整索引列顺序。

内容的提问来源于stack exchange，提问作者Mikael Eliasson