最直接确认mysql表空间是否启用tde加密的方式是查询information_schema.innodb_tablespaces，检查encryption_type为aes且encryption_key_id非零；show create table不反映真实加密状态，物理验证需谨慎在测试环境使用hexdump或strings检查.ibd文件。
查 INFORMATION_SCHEMA.INNODB_TABLESPACES 是最直接的方式
加密状态不体现在 SHOW CREATE TABLE 或表结构里，而是在表空间元数据中。执行以下查询即可确认：
SELECT NAME, ENCRYPTION_TYPE, ENCRYPTION_KEY_ID FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME LIKE '%db_name/t1%';
如果返回的 ENCRYPTION_TYPE 是 AES（不是 NULL 或空字符串），且 ENCRYPTION_KEY_ID 为非零数字，说明该表空间已启用静态加密。
注意：NAME 字段格式为 database_name/table_name（Linux）或 database_name\table_name（Windows），需按实际路径匹配；若查不到，可能是表仍在系统表空间（ibdata1）中，需先迁移至独立表空间。
SHOW CREATE TABLE 只显示声明，不反映真实加密状态
即使你执行过 ALTER TABLE t1 ENCRYPTION='Y'，SHOW CREATE TABLE t1 仍可能不显示 ENCRYPTION='Y' —— 这是正常现象。MySQL 8.0.13+ 才在输出中保留该子句，旧版会直接省略。它只表示建表/改表时的意图，不能作为加密生效的依据。
更危险的是：如果密钥文件损坏或 keyring_file 插件未加载成功，SHOW CREATE TABLE 依然显示 ENCRYPTION='Y'，但磁盘上的数据页仍是明文——这种“假加密”极易被忽略。
用 hexdump 或 strings 直接检查 .ibd 文件（仅限测试环境）
这是验证物理层是否真加密的兜底手段，但仅建议在无业务压力的测试库操作：
- 停掉 MySQL 或对目标表执行
FLUSH TABLES t1 FOR EXPORT;后再读取t1.ibd - 运行
strings /var/lib/mysql/db_name/t1.ibd | head -20：若能看到可读字段名、字符串值，基本可判定未加密（或密钥失效） - 若输出全是乱码或不可见字符，再配合
hexdump -C /var/lib/mysql/db_name/t1.ibd | head -10查看前几行，AES 加密后的数据页开头通常无固定特征，但明文页头有明显InnoDB或TRX标识
⚠️ 生产环境禁止直接读取正在使用的 .ibd 文件，可能引发崩溃；此法无法区分“加密失败”和“密钥不可用”，仅作辅助交叉验证。
为什么 SELECT 查询不出错 ≠ 数据已加密
MySQL 的 TDE 是透明的：只要密钥可用，读写都自动加解密，应用完全无感。所以即使你 SELECT * FROM t1 返回结果正常，也不能证明数据在磁盘上是加密的——它可能只是密钥环插件把主密钥从文件里读出来了，而原始数据页压根没被重写。
关键盲区在于：ALTER TABLE ... ENCRYPTION='Y' 只加密新写入的数据页，旧页仍为明文，直到被 purge、page split 或 DML 覆盖。这意味着刚开启加密后立即做 hexdump，大概率仍看到明文。
真正可靠的验证节奏是：开启加密 → 写入新数据 → 等待后台线程完成页刷新（或手动触发 OPTIMIZE TABLE t1）→ 再检查 INNODB_TABLESPACES + 抽样验磁盘文件。
