Some hosting providers doesn't have localhost as mysql hostname, instead they give-out mysql.example.com as host-name to be used in applications.
Could there be any difference in performance, as they, instead of having 127.0.0.1 (or even localhost) in host-name, use domain-name type hosts (mysql.example.com). Doesn't that take a bit more time to resolve dns to specific IP?
It's very hard to make anything out of your question.
I decided that your question is
Will a remote database at my provider that I can access via
mysql.example.combe slower then a local database that I run on my machine/VPS and that I can access vialocalhost.
The answer is: It depends on many things, among them
and the range will be from "local is a lot faster then remote" to the opposite "the remote is a lot faster".
It's not entirely clear to me what you're asking, but I get the impression you're talking about a web server like Apache or nginx running on the same leased server as your MySql database in a hosting provider's data center. You're worried about the connection from the web server to the database, and the only difference between the two choices is what name you use in the connection string.
Given that scenario, it shouldn't matter which one you use. What can matter is how the two names are routed. Localhost will always be routed through the loopback interface (barring some very strange configuration). mysql.example.com can end up going out a physical interface before looping back in an upstream router our switch somewhere. You want to avoid that scenario: there's an extra hop there, the potential to use metered bandwidth, and also the fact the loopback interface often emulate 10Gbps connections (or better; at least 40Gbps is possible), while your physical interface might only be 1Gbps.
However, this isn't really a property of using the wrong name. It's a property of not having things configured so that this connection uses the loopback interface.
On the other hand, you may be talking about connecting from your local office to a MySql database hosted in a remote data center somewhere. In this case, then yes: it will be much slower, because traffic to the database must pass through your WAN connection and the internet, rather than just the local network (or your personal loopback interface, considering that you are comparing this to localhost).
However, this isn't what I'd call a "production" deployment. What I generally try to do is host all of the parts of an application on the same physical network. If it's a client server app, where the clients runs on user desktops inside a company network, then the database server should also live on that network (note that it doesn't have to be localhost: just not going out through a WAN conneciton). If it's a web app, then the database should be in the same data center (not the same server, but same network switch segment) as the web server, but those two servers can easily be a thousand miles away from the people viewing the web pages.
They use a dedicated database server because it's easier to manage.
Having dedicated database servers and web servers makes it easier to update, easier to backup, etc. If you have everything for a single customer on a single server you have to run updates and backups on every single instance. By separating them you can have as much customers on a given server as the machine can handle.
A server reaches it's limit? Just add another one of the same type.
In most cases the lower speed or higher latency is negligible, if you (the customer) are at a point where it affects your application you can still move to a different kind of hosting, e.g. a root server where you control every aspect, down to which software version you want to install.
When you're using "localhost" notation in fact MySQL uses UNIX domain sockets. They're more performant, comparing to TCP/IP, and for high-load it can make noticeable difference. But UNIX domain is local to the host by its nature, it's not networking, so this implies you can't use remote MySQL server with it.
