Generally, you should configure your database server to listen for database connection on a Unix domain socket or to listen only on localhost. MySQL shouldn't be configured to listen on external IP address, or worst, to listen on all addresses, unless the regular user of the database (usually a web application) is not running on the same machine. And if the application is remote, there are a number of things you need to consider.
The way you do this, is to set bind-address config to the loopback address (127.0.0.1). If you do this, then nobody can connect to MySQL remotely, unless they already have a connection to the server (e.g. SSH) and make a "local" connection from there. In this case, you'll be relying on SSH to do encryption and authentication, and the OS to not route remote packets coming to the loopback address to your application. Additionally, you can configure MySQL to require password/authentication, to restrict local, unprivileged users from connecting to the database. Note that you cannot restrict privileged users (root and someone with unrestrained physical access). Additionally, you can configure a host firewall (i.e. iptable in Linux) to further limit open ports on the system.
You can do remote administration by using SSH local forwarding. You'll configure Workbench to connect to your local machine's local port, and SSH will forward that connection to the MySQL port on the server.
Another way to do remote administration is to configure PHPMyAdmin to listen on a public HTTPS port. In this configuration, you'll be relying on PHPMyAdmin to do authentication and HTTPS for encryption. Note that using PHPMyAdmin via unencrypted HTTP is insecure, you must use HTTPS, also PHPMyAdmin, while convenient, exposes a large attack surface as it's a complex PHP application. For example, it may be vulnerable to CSRF or XSS.
You can further secure PHPMyAdmin by configuring your webserver (e.g. Apache) to require a "TLS client certificate" to access the PHPMyAdmin application. In this configuration, you'll be relying on Apache for authentication and HTTPS for encryption. You should use this in conjunction with PHPMyAdmin's own authentication mechanism.
If your application isn't running on the same machine as your database (common in databases with large number of users or which is shared by multiple applications), you can let MySQL to bind on a privileged network's IP Address. In this security model, anyone that are connected to the privileged network and is allowed by the network admin to send IP packets to the database server is considered trusted. In this case, you'll depend on the server's network administrator. Unless you're experienced with networking and trusts whoever configured the network admin and their firewall configuration, I wouldn't recommend this. Remote administration, in this case, would be done by connecting to the privileged network using a VPN. There need to be a network firewall that prevents connections from outside the privileged network from being routed to the database server. In this configuration, authentication is done by the VPN server, and by the routers enforcing the LAN routing table.
Additionally, you can configure MySQL to require a TLS client certificate. With this configuration, the MySQL server is also doing authentication. This can be used if you don't fully trust the network administrator or if you don't trust all users in the network that's allowed to connect to the database machine.
Finally, you can expose MySQL to bind to a public IP Address.
I do not recommend this, as MySQL is not an application designed to be exposed on a public port (even though MySQL can require TLS client certificate). Apache, sshd, and VPN gateway, on the other hand, are designed so they can be configured to be exposed in a public address securely.
Unless you know you need it, I'd recommend against configuring MySQL to listen on non loopback address. And there's no good reason to deliberately expose a database server on a public IP address for any length of time. This can only be considered misconfiguration or incompetence.
You shouldn't need SOCKS (OpenSSH Dynamic forwarding). SOCKS is only useful if you have large number of target machines and you don't want to configure what local port goes where. In this case, you have a specific target machine, which is your database server on the database port, so you only need to forward that port.