数据库是承载核心数据基础，远程连接能力是实现应用和数据分离的关键，开发者和运维人员要从一台服务器连接到另外一台服务器上的数据库时，第一个需要打交道的就是端口。微软SQL Server和开源MySQL这两大类数据库的默认端口如何自己家门牌号，是建立连接的起点。理解这些端口及其背后的配置逻辑，不仅是连接成功的技术前提，也是保障数据通信安全和高效的基础。

SQL Server的默认端口是1433。这个数字在数据库领域广为人知，几乎成为了SQL Server实例的一个标志。当您在连接字符串中指定服务器地址为“192.168.1.100”时，客户端驱动通常会默认尝试通过TCP 1433端口与数据库引擎建立连接。然而，企业级环境的复杂性远不止于此。出于安全考虑，例如为了减少自动化攻击脚本的骚扰，数据库管理员经常会更改默认端口。此外，在一台服务器上部署多个SQL Server实例的场景也十分常见。在这种情况下，默认实例可能仍使用1433，但每个命名实例在安装时会被动态分配一个随机的TCP端口。为了解决这种寻址的复杂性，SQL Server提供了一个名为“SQL Server Browser”的辅助服务，它运行在UDP 1434端口上。当客户端只提供服务器名和实例名（如“MyServer\MyInstance”）时，会先向服务器的1434端口查询该实例实际监听的端口号，再建立正式连接。

与SQL Server类似，MySQL同样拥有一个标志性的默认端口——3306。无论是原生的MySQL还是其著名分支MariaDB，都继承了这个端口号。在连接MySQL时，如果您没有在连接参数中显式指定端口，客户端库会自动尝试3306端口。一个典型的MySQL连接命令看起来是这样的：

mysql -h 192.168.1.100 -P 3306 -u username -p

这里的`-P`参数（大写）就是用于指定端口的。了解这一点对于诊断连接问题至关重要。如果数据库管理员已将端口改为3307，而您依然尝试连接3306，那么连接请求将如同寄错了地址的信件，永远无法送达，最终导致“Connection refused”（连接被拒绝）的错误。

端口的知晓只是第一步，成功建立远程连接更像是一次通过多重关卡的旅程，其中任何一个环节中断都会导致失败。首先，数据库服务本身必须正在运行并监听正确的端口。您可以在服务器上使用简单的命令来验证这一点：

# 在Linux上，检查MySQL是否在监听3306
netstat -tlnp | grep 3306
# 在Windows上，检查SQL Server是否在监听1433
netstat -an | findstr 1433

其次，数据库必须配置为允许远程连接。这是一个常见的误区：出于安全考虑，许多数据库在安装后默认只接受来自本机（localhost）的连接。对于MySQL，您需要检查`my.cnf`（或`my.ini`）文件中的`bind-address`配置项。如果它被设置为`127.0.0.1`，那么只有本地连接被允许；要允许远程连接，需要将其注释掉或改为服务器的公共IP地址`0.0.0.0`。

ini
# 在MySQL配置文件中
# bind-address = 127.0.0.1  # 这行注释掉或修改为
bind-address = 0.0.0.0

对于SQL Server，则需要通过“SQL Server配置管理器”来启用TCP/IP协议，并确保在“IP地址”选项卡中相应IP的“TCP端口”设置正确且“已启用”状态为“是”。

最后，也是最坚固的一道屏障——防火墙。服务器操作系统和托管机房的网络防火墙必须配置为允许数据包通过您的数据库端口。无论是云服务商的安全组规则，还是Windows防火墙的入站规则，都需要为1433或3306端口创建一个明确的放行策略。一个精确的防火墙规则是打通这条数据通道的最后一把钥匙。

在掌握了端口与连接配置后，我们必须将目光投向一个更重要的主题——安全。将数据库端口直接暴露在公网上，无异于将金库的大门向所有人展示。因此，最佳实践强烈建议采取多层防护措施：首要的是修改默认端口，这是一个简单却极其有效的安全措施，可以规避大量漫无目的的自动化网络扫描。更进一步，可以考虑通过SSH隧道来建立连接，这样数据库端口本身就不需要对公网可见，只有通过安全通道认证的用户才能间接访问。对于云环境，充分利用虚拟私有云（VPC）或私有网络来确保数据库实例与Web应用服务器之间的通信完全在内网中进行，是构建安全架构的基石。