DON'T touch MAXDOP

Why you should rarely remove parallelism.

[thesqlspot]

@Dwayne- I've read the Microsoft literature and setting it to one in the real world for *most* applications is performance suicide. Yes, it's ok for SharePoint because it's a highly tuned app. Most aren't. By the way, after 8 on mdop you won't see much benefit unless you massive cores. 

[dwayne]

In your video you didn't mention what you should set maxdop to other than don't set it to 1, MAXDOP should always be set to the number of physical cores in a single CPU or 8 whichever is lower. Also setting maxdop to 1 is perfectly fine in certain scenarios, SharePoint for example requires maxdop 1 to run optimally

[PyroAardVarK]

While I agree that setting MAXDOP to 1 is a terrible idea, keeping the MAXDOP to 0 isn't really a good idea either.

You need to consider that a MAXDOP of 0 means that SQL Server will thread the query across all available cores, even across NUMA boundaries. Which is why it's a very common recommendation to set MAXDOP to equal the number of cores per each processor (when dealing with an SMP system). E.G., a dual hex-core server should have MAXDOP set to 6.

Coincidentally, setting the 'cost of threshold' value to a number higher than 5 (like 50, as you set in your video) is done to minimize the chance of the SQL thread to be paralleled in the first place, since often times the thread would run faster as a single thread.

Sources:

As always, your mileage may vary, but setting this to mirror your NUMA schedulers seems to be a better set of advice.