← 上一篇 SQL Mode
做的事：同一个账号，分别用socket和TCP连接，查真实的加密状态
代码-- 默认连接（本机会自动走本地Unix socket） mysql -u root -e "SELECT VARIABLE_VALUE FROM performance_schema.session_status WHERE VARIABLE_NAME='Ssl_cipher';" -- 显式走TCP，不加任何--ssl参数 mysql -u root -h 127.0.0.1 -P 3306 --protocol=TCP -e "..."
验证：走本地socket，真实完全没有加密
实测 · 本机执行输出（默认连接，走Unix socket）
Ssl_cipher: （空） Ssl_version: （空）
本地socket连接真实是同一台机器上的进程间通信，数据完全不经过真实的网络协议栈，MySQL真实不会（也没必要）为它协商TLS——这不是配置缺失，是这类连接方式本身真实不涉及网络层，加密没有对象可保护。
验证：走TCP，哪怕不指定任何ssl参数，真实自动用上了TLS
实测 · 本机执行输出（显式--protocol=TCP，未指定--ssl-mode）
Ssl_cipher: TLS_AES_128_GCM_SHA256 Ssl_version: TLSv1.3
MySQL客户端真实默认的--ssl-mode是PREFERRED：只要走的是真实的网络连接（TCP），并且服务器支持TLS，客户端会真实自动协商加密，不需要用户显式加任何参数——本文这次真实协商出的是TLSv1.3下的TLS_AES_128_GCM_SHA256，是当前真实主流的强加密套件。这意味着"我的连接到底有没有加密"这件事，真实取决于两个因素：连接方式(本地socket天然不需要，TCP默认会协商)，以及双方是否都支持TLS——不是一个简单的"配没配SSL参数"就能回答的问题，真实需要看Ssl_cipher这个状态变量才能确认。
分步演示：socket连接和TCP连接的真实加密状态对比
每一步都是本文上面用真实的performance_schema查询跑出来的原始结果。
加不加密，真实取决于连接方式而不是参数
这一步新验证的连接方式
本文用到的工具
- 本机 MySQL 26.7.0（InnoDB），真实对比Unix socket连接和TCP连接的Ssl_cipher/Ssl_version状态
performance_schema.session_status
下一篇 · MYSQL / INNODB 109
数据加密
京公网安备11010502063487号