Securing MySQL server from remote connection

The specific issues depend to some extent on the precise reasons you're opening the server in this way. However, I'm not sure what the difference between a direct MySQL connection dropping (which could happen anyway) and an SSL tunnelled connection dropping, in terms of levels of worry.

1. Changing the port is essentially security by obscurity. It might reduce the number of attacks seen slightly, but I've never seen particularly high levels of traffic against any database ports when compared with what is commonly seen against, say, SSH ports. There is no harm in doing it, as long as it is not the only security precautions taken. Don't expect it to stop anyone targeting your server specifically though.
2. SSL Connections for MySQL are sensible. Make sure your clients are aware of the specific certificate to expect, else it would be possible for a MitM attack to take place by interception and re-encryption (client->attacker is encrypted with attacker cert, attacker decrypts and sends to server using server cert, server responds to attacker, who re-encrypts the data to return to client)
3. IP restrictions are good. You can apply defence in depth here - IPTables to allow for connections to the server, then specific users within MySQL to only be allowed from specific source IPs. Be aware of any users coming from dynamic or shared IP ranges - this mostly applies to users who require access from mobile devices in some countries, but can also result from corporate NATs.
4. This is also good. Ensure that root still has a strong password, and does not rely on access from localhost as the only security precaution - in particular, allowing access to specific hosts indiscriminately, even if that is localhost, is a bad idea, since it weakens the security level to that of the lowest privilege user with access to that host.

However:

• Are your clients storing access passwords in an unencrypted form? (e.g. are they using software to access the system which doesn't restrict access to the passwords if they click "remember my password"?) This might be addressed by policy (saying "don't click remember my password") or by technology (enforcing a specific client which doesn't have this function, or safely implements the function)
• Is the stored data sensitive enough to warrant at-rest encryption?
• Are you storing logs for the system, and monitoring these regularly?
• Does the web server have access to any data it does not specifically require? (e.g. if it doesn't need to be able to read the MySQL users table, has it been prevented from doing so?)

Essentially, without knowing the specific details of your setup, any answer can only offer suggestions of what would normally be considered "secure enough". For a bank or for medical records, I would suggest that your setup is not secure enough, and that you should get in a specialist to help secure it fully. For a brochure website, with no transaction data, and no customer data, it's probably fine. For anything between them, it varies.

One thing I can think of: Setting up SSL may not enforce all connections to be SSL. Be sure to verify that.

Aside from the above concern, I think it would only be vulnerable if there was a bug in Mysql itself. If you want to mitigate that, use a VPN (which is not unlike SSH tunneling, as it is an extra point of potential failure), and tell Mysql to only bind to the VPN's vitrual network interface (e.g. tun0).