Two ways I know of to do this:
1. In an UPDATE trigger, you can query UPDATE() function (http://msdn.microsoft.com/en-us/library/ms187326.aspx) to tell you if the column was SET by the UPDATE statement. Unfortunately, it does not tell you whether it changed or not (but you could test this by comparing the values for INSERTED.column vs. DELETED.column using those pseudo tables.
2. Use an OUTPUT clause of UPDATE to dump the updated results to a temporary table. I believe you can also reference INSERTED.* and DELETED.* psuedo tables there to dump all columns into the temp table. Then you have to query back from the temp table to see what was changed.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St