Strange oracleclient Phenomenon

For SQL statements
Select nvl (to_char (floor (AVG (apfndtm-apdldtm) * 24*3600), 0) from emflib. eqapypf
Where apydat> = 20080902 and apydat <= 20080902 and apcfmfg = 'C' and apapyfg = 'A' and apytim> = 090000 and apytim <= 173000 and apdeal> = 0 and apntg3 = 0 and apctg4 = 'fangxn'

If you use parameterized
Slow speed
Select nvl (to_char (floor (AVG (apfndtm-apdldtm) * 24*3600), 0) from emflib. eqapypf
Where apydat >=: apydat1 and apydat <=: apydat2 and apcfmfg =: apcfmfg and apapapyfg =: apapapyfg and apytim >=: apytim1
And apytim <=: apytim2 and apdeal> =: apdeal and apntg3 =: apntg3 and apctg4 =: apctg4

If the following clause is missing a condition, the speed is okay.
Select nvl (to_char (floor (AVG (apfndtm-apdldtm) * 24*3600), 0) from emflib. eqapypf
Where apydat >=: apydat1 and apydat <=: apydat2 and apcfmfg =: apcfmfg and apapapyfg =: apapapyfg and apytim >=: apytim1
And apytim <=: apytim2 and apdeal> =: apdeal and apntg3 =: apntg3

If you change SQL
Select nvl (to_char (floor (AVG (apfndtm-apdldtm) * 24*3600), 0) from emflib. eqapypf

Where apydat >=: apydat1 and apydat <=: apydat2 and apcfmfg =: apcfmfg and apapapyfg =: apapapyfg and apytim >=: apytim1

And apytim <=: apytim2 and apdeal> =: apdeal and apntg3 =: apntg3 and apctg4 = 'fangxn'
So the speed is violent and fast. It's really hard to understand why. Data Distribution
Apctg4 count (*)
1 huangjf 106
2 zhangyj 117
3 linliju 2
4 weisq 53
5 zhangdc 28
6 fangxn 217
166 ldwangl
8 linyz 166
9 shixy 184
163 shaonh
11. liyy 160
12 ldchenwf 9

It is estimated from experience that although it is all SQL parameters, the SQL access plan may use full table scan because of the data distribution or the SQL statistics are not timely, using Direct SQL can make it back to the correct track. However, it seems that the knowledge of Oracle is not deep enough. If someone knows it, please tell the reason. It is really not as deep as digging.