Short answer: No, it does not improve performance any more than setting those tuning options yourself.
The variable innodb_dedicated_server is explained in detail when the feature was announced (2017-08-24):
https://mysqlserverteam.com/plan-to-improve-the-out-of-the-box-experience-in-mysql-8-0/
It's just a shorthand for a number of tuning options. The new variable doesn't improve performance in any special way, it's exactly the same as setting those other tuning options yourself.
I wrote this comment on the blog when they announced the feature:
I’m sorry, but I don’t like this feature at all. I understand the goal of improving the out-of-the-box experience for naive users, but I don’t think this solution will be successful at this goal.
Trying to pre-tune a MySQL installation with some formula is a one-size-fits-all solution, and these kinds of solutions are unreliable. We can recall examples of other products that have tried to do this, but eventually removed their auto-tuning features.
It’s not a good assumption that the buffer pool needs as much physical RAM as you can afford. You already know this, because you need the innodb_dedicated_server option. Rick mentioned the possibility that the dataset is already smaller than RAM. In this case, adding more RAM has little or no benefit.
Many naive users mistakenly believe (after reading some blog) that increasing RAM allocation always increases performance. It’s difficult to explain to them why this is not true.
Likewise innodb log file. We assume that bigger is better, because of benchmarks showing that heavy write traffic benefits from bigger log files, because of delaying checkpoints. But what if you don’t have heavy write traffic? What if you use MySQL for a blog or a CMS that is 99% reads? The large log file is unnecessary. Sizing it for an assumed workload or dataset size has a high chance of being the wrong choice for tuning.
I understand the difficulty of asking users questions during installation. I recently did a project automating MySQL provisioning with apt. It was annoying having to figure out debconf to work around the installation prompts that do exist (btw, please document MySQL’s debconf variables!).
There’s also the problem that even if you do prompt the user for information, they don’t know the answers to the questions. This is especially true of the naive users that you’re targeting with this feature.
If the installer asks “Do you use MySQL on a dedicated server?” do they even know what this means? They might think “dedicated” is simply the opposite of shared hosting.
If the installer asks “Do you want to use all available memory on this system?” you will be surprised at how many users think “memory” refers to disk space, not RAM.
In short: (1) Using formulas to tune MySQL is error-prone. (2) Asking users to make choices without information is error-prone.
I have an alternative suggestion: Make it easier for users to become less naive about their choices.
I think users need a kind of friendly cheat-sheet or infographic of how to make tuning decisions. This could include a list of questions about their data size and workload, and then a list of performance indicators to monitor and measure, like buffer pool page create rate, and log file write rate. Give tips on how to measure these things, what config options to change, and then how to measure again to verify that the change had the desired effect.
A simple monitoring tool would also be useful. Nothing so sophisticated as PMM or VividCortex for long-term trending, but something more like pt-mext for quick, ephemeral measurements.
The only thing the installation process needs to do is tell the user that tuning is a thing they need to do (many users don’t realize this), and refer them to the cheat-sheet documentation.
