MySql 两张表发生了死锁

[ShutTheFu2kUP]

表 A

a_id int (主键)
a_name varchar

表 B

b_id int (主键)
b_name varchar
a_id int (代码维护的外键，有个单独的索引'idx_a_id')

show engine innodb status

1. 事务 1

SQL: delete from b where a_id = 123
等待锁: b 表的索引 idx_a_id

1. 事务 2

SQL: update a set a_name = 'xxx' where a_id = 123
持有锁: b 表的索引 idx_a_id
等待锁: a 表的索引 PRIMARY

---

两张表的外键关系是代码维护的，为什么 a 还能持有 b 的锁，两个 SQL 的关系只有 a_id 是一样的，今年刚毕业，对底层确实不太了解，希望大佬解答一下原因和优化方式

因为这个事务里封装了多个SQL的调用，同时前端不知道因为什么原因在一秒内调用了N次接口，导致了并发操作导致了死锁。除了防止同时多次调用还有办法避免死锁吗？

@Transational
public void function() {

    delete from b where a_id = 123 // 调用执行该sql

    update a set a_name = 'xxx' where a_id = 123 // 调用执行该sql
    
}

看了两天的文章，大概有了个推论

函数

@Transational
public void function() {

    select * from a where a_id = 123 // 调用执行该sql

    update a set a_name = 'xxx' where a_id = 123 // 调用执行该sql
    
}

1. 两个事务T1，T2并发执行select语句，此时T1，和T2都拥有S锁
2. 继续执行，T1要执行update，但是发现该行数据还有T2的S锁，所以等待T2释放S锁
3. T2也要执行update，也发现改行有T1的S锁，所以等待T1的S锁释放，此时因为都在互相等待对象的锁释放，所以形成了死锁

根据以上的推论写方法测试了一下，但是发现Java中@Transational内的方法select好像并没有加共享锁，有大佬看看是怎么个问题吗？