具体问题在某种程度上取决于您以这种方式打开服务器的确切原因。但是，就担忧程度而言，我不确定直接 MySQL 连接断开（无论如何都可能发生）和 SSL 隧道连接断开之间的区别。

1. 更改端口本质上是默默无闻的安全性。它可能会略微减少攻击的数量，但与常见的针对 SSH 端口的攻击相比，我从未见过针对任何数据库端口的流量特别高。这样做没有害处，只要它不是唯一采取的安全预防措施。不要指望它会阻止任何人专门针对您的服务器。
2. MySQL 的 SSL 连接是明智的。确保您的客户端知道预期的特定证书，否则有可能通过拦截和重新加密来发生中间人攻击（客户端->攻击者使用攻击者证书加密，攻击者解密并使用服务器发送到服务器证书，服务器响应攻击者，攻击者重新加密数据返回给客户端）
3. IP限制很好。您可以在此处应用深度防御 - IPTables 以允许连接到服务器，然后仅允许 MySQL 中的特定用户来自特定源 IP。请注意来自动态或共享 IP 范围的任何用户 - 这主要适用于在某些国家/地区需要从移动设备访问的用户，但也可能来自公司 NAT。
4. 这也很好。确保 root 仍然有一个强密码，并且不依赖从 localhost 的访问作为唯一的安全预防措施 - 特别是，允许​​不加选择地访问特定主机，即使是 localhost，这是一个坏主意，因为它会削弱安全级别到有权访问该主机的最低权限用户的权限。

然而：

• 您的客户是否以未加密的形式存储访问密码？（例如，如果他们单击“记住我的密码”，他们是否使用软件来访问不限制访问密码的系统？）这可能通过策略（例如“不要单击记住我的密码”）或技术来解决（强制执行没有此功能的特定客户端，或安全地实现该功能）
• 存储的数据是否足够敏感以保证静态加密？
• 您是否为系统存储日志并定期监控这些日志？
• Web 服务器是否可以访问它不特别需要的任何数据？（例如，如果它不需要能够读取 MySQL 用户表，它是否被阻止这样做？）

本质上，在不知道您设置的具体细节的情况下，任何答案只能提供通常被认为“足够安全”的建议。对于银行或医疗记录，我建议您的设置不够安全，您应该请专家帮助完全保护它。对于没有交易数据和客户数据的宣传册网站，这可能没问题。对于他们之间的任何事情，它都会有所不同。

我能想到的一件事：设置 SSL 可能不会强制所有连接都是 SSL。请务必验证。

除了上述问题之外，我认为只有在 Mysql 本身存在 bug 的情况下它才会容易受到攻击。如果你想减轻这种情况，请使用 VPN（这与 SSH 隧道不同，因为它是潜在故障的额外点），并告诉 Mysql 仅绑定到 VPN 的虚拟网络接口（例如 tun0）。