看起来你遇到的是压测场景下典型的MySQL行锁竞争问题，结合你描述的小表、事务包裹、压测时才出现的特征，咱们来拆解可能的核心原因：

一、核心原因：热点行的行锁竞争（最可能） #

你的表只有10行，而压测时大量请求会触发针对key = operation_key这一行的UPDATE——哪怕是基于主键的精准更新，InnoDB也会为目标行加排他行锁。当多个事务同时争抢同一行的锁时，就会形成等待队列：

• 先到的事务持有锁执行，后续事务必须等待锁释放才能继续，这直接导致你看到的Lock_time: 1.370841（锁等待时间占了总耗时的大部分）。
• 加上你的UPDATE是包裹在创建页面的事务里，如果事务还包含其他操作（比如插入页面数据、查询关联表），锁会被持有更长时间，压测下这种竞争会被瞬间放大，最终触发Lock wait timeout exceeded错误。

二、事务过大导致锁持有时间过长 #

如果这个UPDATE所在的事务不止包含这一条更新，还涉及其他业务逻辑（比如创建页面时的多表写入、复杂查询），整个事务的执行时长会被拉长，行锁的持有时间也会同步增加。在压测的高并发场景下，这种“长事务”会让更多后续请求陷入锁等待，进一步加剧超时问题。

三、InnoDB锁机制的细节影响 #

虽然你是基于主键更新，但还有几个细节可能放大问题：

• 事务隔离级别：MySQL默认的REPEATABLE READ隔离级别下，InnoDB会使用Next-Key Lock（行锁+间隙锁），不过针对主键的精准匹配一般不会触发间隙锁，但如果你的operation_key不是主键（你提到update是按主键，这里可能是笔误？），或者表上有其他索引，可能会导致锁范围扩大。
• 锁升级：虽然InnoDB是行级锁，但极端情况下如果同一事务锁定了表中大量行，可能触发锁升级为表锁，但你的表只有10行，这种概率极低，但也可以排查下。

四、数据库资源或连接池瓶颈 #

压测时如果数据库连接池配置不足，请求会先在连接池排队等待可用连接，再加上后续的锁等待，总耗时就会超过1秒。不过从你的Lock_time数据来看，锁等待是主要因素，但连接池瓶颈会雪上加霜。

排查与优化建议 #

• 查看锁状态：执行SHOW ENGINE INNODB STATUS;，在TRANSACTIONS部分找到等待锁的事务和持有锁的事务，确认它们的执行逻辑，看是否有长事务占用锁。
• 分析慢事务：开启慢查询日志，记录整个创建页面事务的完整执行时长，定位事务中拖慢速度的环节，尽量缩短锁持有时间（比如把UPDATE放在事务的最后执行）。
• 解决热点行问题：如果operation_key对应的是固定的热点行，可以考虑拆分热点数据——比如把计数器拆成多个分片（比如拆成10个计数器，每次随机更新一个，最后求和），分散锁竞争。
• 调整锁超时参数：如果业务允许，可以适当调大innodb_lock_wait_timeout参数（默认是50秒），但这只是缓解手段，核心还是要解决锁竞争问题。

备注：内容来源于stack exchange，提问作者Nerub