你在公司写程序，连接数据库的时候有没有想过，账号密码是怎么不被别人截获的？比如你在家连公司的MySQL，中间经过公共WiFi，要是有人偷看网络流量，岂不是什么都暴露了？这时候就得靠数据加密传输。
为什么需要加密传输
数据库经常要跨网络通信，比如App服务器连云数据库，或者远程管理工具连生产库。这些数据在网上传输时，就像寄信一样，中途可能被拦截。如果内容是明文，比如用户名、密码、用户资料，那等于把家门钥匙挂在网上任人拿。
曾经有个开发同事图省事，用明文连接数据库，结果公司内网被人嗅探，整张用户表都被拖走了。后来查日志才发现，攻击者就是通过交换机镜像抓包拿到连接信息的。
加密传输的基本思路
核心就一点：让数据在发送前“变形”，接收方再“还原”。中间就算被截获，看到的也是一堆乱码。这个过程依赖加密算法和密钥。
最常见的方案是TLS（Transport Layer Security），也就是以前说的SSL。你现在访问https网站，背后就是TLS在干活。数据库也能用这套机制。比如MySQL支持SSL连接，PostgreSQL也有类似的加密配置。
以MySQL为例开启加密连接
先确认服务端是否启用SSL：
SHOW VARIABLES LIKE '%ssl%';如果have_ssl为YES，说明支持。然后客户端连接时加上参数：
mysql -u user -h db.example.com -p --ssl-mode=REQUIRED这样即使网络被监听，抓到的数据也是加密的，没法直接读取原始SQL语句或返回结果。
对称加密 vs 非对称加密
对称加密，比如AES，加密解密用同一把钥匙。速度快，适合大量数据加密。但问题是怎么安全地把钥匙交给对方？万一传钥匙的时候被截获，就白搭了。
非对称加密，比如RSA，有一对密钥：公钥和私钥。公钥可以公开，用来加密；私钥必须保密，用来解密。你用对方的公钥加密数据，只有他用自己的私钥才能解开。这就解决了密钥分发的问题。
TLS握手阶段用的是非对称加密来协商出一个临时的对称密钥，之后的数据传输都用这个对称密钥加密，兼顾了安全性和效率。
实际场景中的注意事项
别以为开了SSL就万事大吉。有些应用虽然连接用了加密，但日志里却把SQL语句原样打出来，包含敏感字段，这同样危险。还有些老旧系统硬编码了数据库密码，在代码仓库里裸奔。
另外，证书有效性也得管。自签名证书虽然能加密，但容易被中间人攻击。最好用受信任CA签发的证书，或者内部搭建私有CA，统一管理。
现在很多云数据库默认开启强制加密连接，比如阿里云RDS、AWS RDS，就是为了避免用户疏忽。你连上去的时候，驱动会自动验证证书，不符合规则就断开。
小技巧：本地测试怎么模拟加密环境
开发时想测SSL连接，又不想买证书？可以用OpenSSL自己生成一套：
openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca.pem
openssl req -newkey rsa:2048 -days 365 -nodes -keyout server-key.pem -out server-req.pem
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 365 -CA ca.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem然后把server-cert.pem和server-key.pem配进数据库服务，客户端用ca.pem验证，就能跑通整个链路。
数据加密传输不是高深莫测的技术，它是现代数据库应用的标配。只要你碰网络，就得考虑这层防护。别等出事了才想起来补漏，那时候损失早就无法挽回了。