I've built a statement that searches in the existing indexes those that are suitable for FK indexes on the primary tables (since the referenced tables already have unique indexes no need to worry about those).
I've found lots of missing indexes but some could be achieved by switching the columns order on existing indexes... but it's risky, right? An index with colA, colB can be used for both colA and colA + colB searches and nothing grantees that it's only used with colA + colB so I can switch the order to colB, colA so it can used for a constraint check by colB... So is it best o have a new index on colB?
Also, and this only comes with time and making mistakes, I use the DMV to see what indexes were bad (lots of writes, only 10% or less reads...) and I disabled them..... Big mistake cause some of those were FK constraint checks on primary tables... A DELETE operation took 9s instead o 1ms... Lesson learned: when disabling an index make sure it's not used for FK constraint checks... The one time it'll be used you'll notice it!!!
If you need to work better, try working less...