MySQL不支持事务优先级配置，InnoDB无抢占式调度机制，锁分配基于先到先得和死锁检测回滚，系统表与状态输出中不存在priority相关字段，innodb_lock_wait_timeout仅控制等待超时而非优先级。
MySQL 本身不支持事务优先级（Transaction Priority）配置。 你无法像 Oracle 23ai 或 YugabyteDB 那样用 SET SESSION TRANSACTION PRIORITY 或 yb_transaction_priority_upper_bound 来显式设定事务“谁先谁后”。InnoDB 没有抢占式调度，也没有基于优先级的锁分配机制。
为什么 SHOW ENGINE INNODB STATUS 里看不到优先级字段
InnoDB 的锁调度完全依赖两个底层逻辑：一是“先到先得”（FIFO），二是死锁检测后的自动回滚决策。它不维护任何事务优先级元数据，所以所有系统表（如 INNODB_TRX、INNODB_LOCK_WAITS）和状态输出中都不存在 priority、weight、level 等相关列。你看到的 trx_weight 是死锁分析时临时计算的值（基于 undo log 大小、锁数量等），不是可配置的优先级标识。
innodb_lock_wait_timeout 不是优先级开关
这个参数常被误认为能“提升高优事务胜率”，但它只控制单个语句在等待锁时最多忍多久：
-
SET innodb_lock_wait_timeout = 3;—— 低优事务等锁超 3 秒就报ERROR 1205 (40001): Lock wait timeout exceeded，然后回滚 - 它不会让高优事务插队抢锁，也不会让低优事务“主动礼让”
- 若高优事务也卡在等锁，且对方持有锁时间长，它一样要等，timeout 值对它无加速作用
- 盲目调小该值可能导致大量低优事务反复失败重试，反而加重锁竞争
真正能缓解争抢的间接手段
既然没有原生优先级，就得从行为上做隔离和错峰：
- 把高频更新关键行的逻辑（如订单支付、库存扣减）拆成独立短事务，用
COMMIT尽快释放行锁；避免在其中嵌套日志写入、远程调用等长耗时操作 - 对后台批量任务（如报表统计、历史归档），统一加锁前检查：
SELECT COUNT(*) FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT'，发现争抢则延迟执行 - 应用层用 Redis 实现轻量级优先级队列：高优请求进
priority_queue，低优进batch_queue，DB 写入按队列顺序串行提交 - 对同一张表的读写冲突，考虑用
READ COMMITTED隔离级别替代默认的REPEATABLE READ—— 它不加间隙锁，减少因范围查询引发的隐式锁扩大
最易被忽略的一点：所谓“高优先级事务”，本质是“锁持有时间短 + 锁粒度小 + 启动时机可控”。InnoDB 不认身份，只认行为。盯着 trx_started 和 trx_rows_locked 这两个字段做监控，比纠结“怎么设 priority”管用得多。
