Oracle11g Oracle存储过程性能

我的一个存储过程面临性能问题。 以下是伪代码：

PROCEDURE SP_GET_EMPLOYEEDETAILS(P_EMP_ID IN NUMBER, CUR_OUT OUT REF CURSOR)
IS
BEGIN
  OPEN CUR_OUT FOR
    SELECT EMP_NAME, EMAIL, DOB FROM T_EMPLOYEES WHERE EMP_ID=P_EMP_ID;
END;

上面的存储过程大约需要20秒来返回结果集，假设p_EMP_ID=100

但是，如果我在存储过程中将employee ID硬编码为100，则存储过程将在40毫秒内返回结果集

因此，当值被硬编码而不是读取参数值时，同一存储过程对同一参数值的行为不同

表T_EMPLOYEES有大约100万条记录，EMP_ID列上有一个索引

---

如果您能为我提供有关如何改进此存储过程的性能或此处可能存在的问题的帮助，我们将不胜感激。

这可能是由于数据分布不均和/或直方图不完整和/或系统调优不好造成的问题

查询的快速版本可能使用索引。慢速版本可能正在进行全表扫描

为了知道该做什么，Oracle必须知道数据的基数（在您的情况下，将返回多少个结果）。如果它认为会返回很多结果，它将直接进行全表扫描，因为它不值得使用索引的开销。如果它认为返回的结果很少，它将使用索引来避免扫描整个表

这些问题是：

如果使用文字值，Oracle确切地知道在直方图中查找的位置，以查看将返回多少结果。如果使用绑定变量，则更复杂。当然，在Oracle 10上，它没有很好地处理这个问题，只是猜测了基数。在Oracle11上，我不确定它是否可以做一些叫做“绑定变量窥视”的事情，请参阅

即使它知道实际值，如果直方图不是最新的，它也会得到错误的值

即使它能够准确猜测将返回多少结果，您仍然依赖于Oracle系统参数是否正确

最后一点。。。基本上，Oracle有一些参数告诉它，它认为FTS的速度与索引查找的速度相比有多快。如果这些都不正确，它可能会进行FTS，即使速度慢得多。看

---

我的经验是，甲骨文倾向于过早地转向FTS。理想情况下，随着结果集规模的增长，从使用索引到使用FTS，性能应该平稳过渡，但实际上，系统似乎是为了支持批量工作而设置的。

我的第一个猜测是参数类型（本例中的数字）之间的错配数据库列的类型，但由于您的代码只是伪代码，很难判断是否会出现这种情况……我已经验证了该列的数据类型。这是电话号码。非常感谢您的回复。没有问题。我一直都有这个问题。如果你觉得答案有用，别忘了投赞成票。