Is there anything I can do to increase performance in the future once table gets bigger?
If all queries are of the form:

select * from testtable where C_CustomerID = 12345678


then what you have already is not entirely unreasonable. There is a cost to retrieving columns not covered by the nonclustered index from the base table (currently a heap), but unless there are many rows per C_CustomerID, this may not be a practical concern.

That said, the current arrangement is not ideal. There is a chance that SQL Server will decide to scan the whole heap for matches, rather than seek into the nonclustered b-tree index and then perform multiple single-row lookups.

In the absence of any other considerations, I would probably replace the nonclustered index with a (non-unique) clustered index:

DROP INDEX inx_profitability ON dbo.testtable;
GO
CREATE CLUSTERED INDEX [CX dbo.testtable C_CustomerID]
ON dbo.testtable (C_CustomerID);


The clustered index defines the logical ordering of the rows in the table, and provides direct access to the whole row (so no lookups needed). To a large extent, a clustered index is largely 'free', since it is not a separate structure with a copy of (some of) the data.

For rows with the same C_CustomerID, SQL Server will add a hidden integer 'uniquifier' to ensure each row is uniquely identifiable internally. You cannot reference this value directly, but it does add a small overhead.

Making this a clustered table (by adding the clustered index) will also likely improve unused future space management for the table, in the event you delete rows (the question mentions an export).

You might choose to specify a fill factor on the clustered index build above (and when performing maintenance) e.g. by adding WITH (FILLFACTOR = 70). This will reserve a proportion of free space at the leaf levels for future inserts (remember the rows and pages are logically ordered by C_CustomerID). The choice of 70 is entirely arbitrary. The value you choose (if any) is entirely situation-dependent. If all queries are as shown above, there is probably little need to specify a fill factor.

In principle, every table should have a key (primary or otherwise) that enforces whatever real-world combination of columns uniquely identifies each row. This could be a nonclustered primary key or unique constraint in your case.