慢查询里混着锁等待：怎么把「锁等型慢SQL」从「索引型慢SQL」里区分出来

【背景】 我在做一套交易系统的慢查询治理，主库 MySQL 8.0.32（单主 16C64G，innodb_buffer_pool_size=32G），核心表 t_trade 约 8000 万行、二级索引 idx_uid_created (uid, created_at)。慢日志阈值 slow_query_time=1s。

【现象】 慢日志里有一批 UPDATE / SELECT ... FOR UPDATE 的语句，执行计划 EXPLAIN 显示 type=ref、key=idx_uid_created、rows≈20，按理应该是毫秒级，但实际跑了 1.5s~3s。我把它们和「明显的索引缺失全表扫描」混在一起，第一反应是「索引没走对」，结果加索引、改写 SQL 都没用，耗时纹丝不动。后来怀疑这些其实是锁等待（等上游大事务/长事务持有的行锁），只是被慢日志统一记成了「慢 SQL」。

【已尝试的排查与结果】

1. EXPLAIN / EXPLAIN ANALYZE：执行计划正常，扫行很少，排除索引问题；
2. 看 performance_schema 的 events_waits_summary：确认有 row_lock 等待，但没建立「哪条慢 SQL 对应哪次锁等待」的映射；
3. 用 SHOW ENGINE INNODB STATUS 抓到过 LOCK WAIT 段，但那是快照，抓不全、也回溯不了慢日志里那一批。

【期望得到的答案形态】 希望能给出一套可复现的识别方法：如何从慢日志 / performance_schema / information_schema.innodb_trx 里，把「锁等待型慢 SQL」和「索引型慢 SQL」可靠地区分开（具体到表名、字段、查询语句或 SQL 片段示例），以及锁等型慢 SQL 下一步该往哪个方向查（比如定位持锁事务、区分是长事务还是死锁重试），最好附上判断时看的字段和顺序。