mysql 8.0表空间加密不新增锁类型，但因aes-256加解密延长i/o耗时，导致行锁持有时间拉长、事务延迟加剧，从而放大原有锁竞争；典型表现为innodb_row_lock_time_avg飙升、锁等待暴涨，根因多为索引失效或缓冲池不足被加密暴露。
表空间加密本身不直接引入锁开销，但会显著放大已有锁竞争的延迟表现——排查重点不是“加密加了什么锁”，而是“加密让哪些锁变慢了”。
为什么ENCRYPTION='Y'会让锁等待时间飙升
MySQL 8.0 的表空间加密（InnoDB 表空间级）使用 AES-256，所有页读写都需加解密。这不会新增锁类型，但会延长单次 I/O 操作耗时，尤其在高并发更新场景下：
– 持有行锁的时间 = 原逻辑耗时 + 加密/解密耗时
– 若 UPDATE 涉及二级索引维护，可能触发多次页读写，每页都加密，锁持有窗口被拉长
– innodb_buffer_pool_size 不足时，频繁刷脏页 + 加密写盘，进一步拖慢事务提交速度，间接延长锁持有期
- 典型现象：未加密时
innodb_row_lock_time_avg为 2ms，加密后跳到 15ms+，且innodb_row_lock_waits暴涨 - 不是加密“导致”死锁，而是把原本可快速释放的锁，拖成了阻塞源
- 加密对只读查询影响极小，但对
UPDATE/DELETE/INSERT ... ON DUPLICATE KEY UPDATE类语句延迟敏感
用performance_schema.data_locks确认加密是否加剧锁粒度
加密不改变锁行为，但若因性能下降导致事务执行变慢，可能意外扩大锁范围（比如本该走索引却因 CPU 被加解密占满而退化为全表扫描）。验证方式：
- 先查出慢事务的
ENGINE_TRANSACTION_ID（来自INNODB_TRX） - 再查
SELECT * FROM performance_schema.data_locks WHERE ENGINE_TRANSACTION_ID = ? AND LOCK_TYPE = 'RECORD' - 重点看
LOCK_DATA是否出现大量非预期值（如本应只锁 3 行，实际锁了 300 行），以及INDEX_NAME是否为PRIMARY或预期二级索引 - 若发现锁范围异常扩大，立即回退到
EXPLAIN对应 SQL，检查type和key字段——加密不是根因，索引失效才是
监控加密表的 I/O 与锁耦合指标
加密表的锁问题本质是 I/O 延迟和锁持有时间的乘积效应。必须交叉比对三组指标：
-
SHOW STATUS LIKE 'Innodb_data_fsyncs'和Innodb_data_waits：加密后 fsync 次数不变，但Innodb_data_waits显著上升，说明写盘排队加剧 -
SELECT * FROM sys.innodb_lock_waits中的waiting_trx_started与blocking_trx_started时间差：若差值普遍 > 100ms，且阻塞方正在执行UPDATE或INSERT，基本可锁定是加密放大了单事务延迟 -
performance_schema.file_summary_by_event_name中过滤event_name LIKE 'wait/io/file/innodb/%'：对比加密/未加密表的AVG_TIMER_WAIT，若相差 3 倍以上，说明加解密已成 I/O 瓶颈
绕过加密干扰，定位真实锁瓶颈
生产环境不能临时关加密，但可以隔离变量做判断：
- 在相同负载下，用
CREATE TABLE t_enc LIKE t; ALTER TABLE t_enc ENCRYPTION='Y'; INSERT INTO t_enc SELECT * FROM t;构建镜像表，只对新表压测，排除业务逻辑变更干扰 - 用
SET SESSION innodb_flush_log_at_trx_commit = 2临时降低刷盘严格性（仅测试用），若锁等待锐减，说明是加密 + 强制刷盘双重压力所致 - 检查
information_schema.INNODB_TABLESPACES中加密表的ENCRYPTION和STATE，避免误将STATE = 'copying'（在线 DDL 中）当成正常加密状态——这种状态下锁行为完全不同
真正棘手的从来不是加密开关本身，而是它把原本被忽略的索引缺失、长事务、缓冲池不足等问题，以锁等待的形式尖锐地暴露出来。加密只是照妖镜，不是妖怪。
