带in子句的SQL索引

我们的应用程序在一个环境中突然变慢了。我所做的唯一更改是更改了SQL。在发布之前，SQL是这样的

Select EmployeeId 
From Employee 
Where Dept='CS' 
  and record_state='ACTIVE' 
  and EmployeeTypeId ='1' 

发布后的SQL是

Select EmployeeId 
From Employee Where Dept='CS' 
 and record_state='ACTIVE' 
 and EmployeeTypeId IN ('1','2')

此表上的索引是员工\状态\ id \索引（部门、记录\状态、员工类型id） 索引尚未更改。这个索引对新SQL没有帮助吗？新SQL是否扫描整个表？我不知道索引如何使用in子句。感谢您的帮助和评论

查询的解释计划是

| Id  | Operation         | Name                     | Rows  | Bytes | Cost (%CPU)|

|   0 | DELETE STATEMENT  |                          |     1 |    57 |     4   (0)|
|   1 |  DELETE           | Employee                 |       |       |            |
|*  2 |   INDEX RANGE SCAN| employee_state_id_index  |     1 |    57 |     4   (0)|
--------------------------------------------------------------------------------

Predicate Information (identified by operation id):


PLAN_TABLE_OUTPUT


   2 - access("C"."Dept"='CS' AND
              "C"."RECORD_STATE"='ACTIVE')
       filter("C"."EmployeeTypeId"='1' OR
              "C"."EmployeeTypeId"='2')

---

我们面临的问题的解决方案是重新编制表的索引。该表有1000万条记录，我们最近清理了表中的数据（当我们意识到我们有重复的记录时），并将其减少到以前记录量的近一半。因此，我们认为我们将尝试重新编制索引，因为无论如何它需要它。这有助于：）

检查执行计划。它将准确地告诉您是否使用了索引。您还应该告诉我们您正在使用哪些DBMS。神谕Postgres？执行计划针对的是

DELETE

语句，而您的问题显示的是

SELECT

语句。因此，很明显，你没有告诉我们你在第一个例子中以

EmployeeTypeId

作为

number

传递，在第二个例子中作为字符传递。这可能会改变计划（计划显示

EmployeeTypeId

是一个

varchar2

，因为Oracle在那里保留了引号）。第二，你确定索引和你描述的完全一样吗？如计划所示，在

EmployeeTypeId

上显示筛选，而不是访问。如果在

EmployeeTypeId

列之前的索引中有另一列，我通常会想到这一点（即索引不理想）。此外，计划中的

行

显示了该查询估计的1行。如果这是关闭的数量级，那么这也会阻碍事情的发展。相对于那些=1的记录，有多少记录的EmployeeTypeID=2？如果许多行的值为2，那么优化器可能不会使用索引和表扫描。请仅针对EmployeeTypeID=2尝试原始SQL。如果这需要很长时间，那么性能问题是数据的函数，而不是查询的函数。请发布语句两个版本的执行计划。