I would rather suggest following index:

create nonclustered index i_feed2 on dbo.fees (feeID, endDate,programAP,programED,programEX,countryCode,gatewayCode) include (amount,currencyCode,feeType,mandatory) with(data_compression=page,online=on)

Including all filter conditions in where clause as index columns would make the index more selective. Adding fields selected or updated as include column(covering index) will remove RID lookup and would create index seek, which performs better than index scan.

Would also suggest you to add partition the table on of the date fields, e.g., endDate (if the data is extremely high in the table, say 10 millions or more) and include this column in the clustered index (e.g., endDate,ID).This will make the data search even more selective, as only one partition has to be referred for data search in many cases.

I would rather suggest following non clustered index:

create nonclustered index i_feed2 
on dbo.fees  
(
feeID, 
endDate,
programAP,
programED,
programEX,
countryCode,
gatewayCode
) 
include
(
amount,
currencyCode,
feeType,
mandatory
)

Including all filter conditions in where clause as index columns would make the index more selective,though some storage cost increases. Adding fields selected or updated as include column(covering index) will remove RID lookup and would create index seek, which performs better than index scan.

I would give priority to performance over storage increase, as storage is cheap these days but we cannot compromise on performance.

If the table data is extremely high(say 10 millions or more) and often used in queries,would also suggest you to partition the table on one of the date fields, e.g., endDate and include this column in the clustered index too (e.g., endDate,ID).This will make the data search even more selective, as only one partition has to be referred for data search in many cases(using endDate as first columns in filter, wherever possible)

I would rather suggest following index:

create nonclustered index i_feed2 on dbo.fees (feeID, endDate,programAP,programED,programEX,countryCode,gatewayCode) include (amount,currencyCode,feeType,mandatory) with(data_compression=page,online=on)

Including all filter conditions in where clause as index columns would make the index more selective. Adding fields selected or updated as include column(covering index) will remove RID lookup and would create index seek, which performs better than index scan.

I would rather suggest following index:

create nonclustered index i_feed2 on dbo.fees (feeID, endDate,programAP,programED,programEX,countryCode,gatewayCode) include (amount,currencyCode,feeType,mandatory) with(data_compression=page,online=on)

Including all filter conditions in where clause as index columns would make the index more selective. Adding fields selected or updated as include column(covering index) will remove RID lookup and would create index seek, which performs better than index scan.

Would also suggest you to add partition the table on of the date fields, e.g., endDate (if the data is extremely high in the table, say 10 millions or more) and include this column in the clustered index (e.g., endDate,ID).This will make the data search even more selective, as only one partition has to be referred for data search in many cases.