Should SQL Server transaction tables always have a surrogate primary key

Question

For a large table of transactions (100 million rows, 20 GB) that already has a primary key (a natural composite key of 4 columns), will it help performance to add an identity column and make that the primary key?

The current primary key (the natural composite primary key of 4 columns) does the job, but I have been told that you should always have a surrogate key. So, could improve performance by creating an identity column and making that the primary key?

I'm using SQL Server 2008 R2 database.

EDIT: This transaction table is mainly joined to definition tables and used to populate reports.

EDIT: If I did add a surrogate key, it wouldn't be used in any joins. The existing key fields would be used.

EDIT: There would be no child tables to this table

Answer 1

Just adding an IDENTITY column and adding a new constraint and index for it is very unlikely to improve performance. The table will be larger and therefore scans and seeks could take longer. There will also be more indexes to update. Of course it all depends what you are measuring the performance of... and whether you intend to make other changes to code or database when you add the new column. Adding an IDENTITY column and doing nothing else would probably be unwise.