A consulta Oracle simples trava dependendo da cláusula WHERE

Não estamos acostumados a usar Oracle, mas temos um grande banco de dados onde uma consulta não exclusiva como

SELECT * FROM employees where department = 'HR'  

está funcionando, os resultados aparecem sem problemas.

Mas quando eu faço

SELECT * FROM employees where employeeID = '3HVtxO-F3004728F87EF61E'  

a consulta do banco de dados oracle está suspensa (espero que um registro volte e tenho certeza de que existe porque copiei e colei o employeeID de outra consulta).

Para as colunas, a única diferença entre as duas é:

department is VARCHAR2(25)  NULL
employeeID is VARCHAR2(50)  NULL

Além disso, o departamento teria muitas correspondências, enquanto o ID do funcionário provavelmente teria 1 (não consigo ver que seja particularmente definido para ser exclusivo na definição da tabela).

Outras características da mesa:

• na verdade não é uma tabela de funcionários, ela tem dados relacionados ao trabalho, então eu a renomeei aqui...
• contém mais de um milhão de linhas e algumas dezenas de colunas
• um pouco de um banco de dados antigo, não tenho certeza de quem o projetou no trabalho há muito tempo, poderia ter problemas de integridade / indexação do banco de dados?
• uma seleção regular * de funcionários sem cláusula where também não funcionaria porque congela em torno da marca de meio milhão de linhas encontradas.

Alguma ideia de por que isso pode estar acontecendo? Devo projetar melhor minha consulta? Como você recomendaria diagnosticar algum problema relacionado a problemas com o próprio banco de dados? Tentando entender esse banco de dados oracle, mas um pouco estranho de se acostumar, pois uma consulta simples que deve retornar um item está suspensa. Obrigada.

Atualização 1: Respondendo aos comentários, não há indexação para esta coluna. Felizmente, esta é uma tabela desatualizada que não será usada, com uma nova versão sendo feita que terá colunas indexadas, então acho que esse foi um problema.

Em relação ao plano para a segunda consulta, fica assim:

Plan hash value: 123724717

------------------------------------------------------------------------------------------------
| Id  | Operation           | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |          |    12 |  4416 |  2376K  (1)| 07:55:19 |       |       |
|   1 |  PARTITION RANGE ALL|          |    12 |  4416 |  2376K  (1)| 07:55:19 |     1 |    14 |
|*  2 |   TABLE ACCESS FULL | [Employee|    12 |  4416 |  2376K  (1)| 07:55:19 |     1 |    14 |
------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1
   2 - SEL$1 / Employees@SEL$1

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("EmployeeID"='3R5MMN-0F9345L9IK8A349A043')

Column Projection Information (identified by operation id):
-----------------------------------------------------------
-- The list of all the columns follows.

Meu palpite é que esta é apenas uma tabela realmente muito bem projetada e não projetada para ficar tão grande, ou para alguém realmente usar muito :) Para fins práticos, passarei para encarnações mais recentes desta tabela que terão indexação e espero que isso resolva.