with referential integrity we get an s-lock explosion.

s-lock-exploder.sql

CREATE TABLE `c` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `parent` bigint unsigned DEFAULT NULL,
  UNIQUE KEY `id` (`id`),
  KEY `parent` (`parent`),
  CONSTRAINT `c_ibfk_1` FOREIGN KEY (`parent`) REFERENCES `c` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1

INSERT INTO `c` VALUES (1,NULL),(2,1),(3,1),(4,2),(5,2),(6,3),(7,3),(8,3);

start transaction read write;
select * from c where id = 8 for update;
select object_name, index_name, lock_type, lock_mode, lock_data, lock_status from performance_schema.data_locks;
update c set id=9 where id =8;
select object_name, index_name, lock_type, lock_mode, lock_data, lock_status from performance_schema.data_locks;

start transaction read write;
select * from c where id = 8 for update;
select object_name, index_name, lock_type, lock_mode, lock_data, lock_status from performance_schema.data_locks;

We get

+-------------+------------+-----------+---------------+-----------+-------------+
| object_name | index_name | lock_type | lock_mode     | lock_data | lock_status |
+-------------+------------+-----------+---------------+-----------+-------------+
| c           | NULL       | TABLE     | IX            | NULL      | GRANTED     |
| c           | id         | RECORD    | X,REC_NOT_GAP | 8         | GRANTED     |
+-------------+------------+-----------+---------------+-----------+-------------+

As we continue

update c set id=9 where id =8;
select object_name, index_name, lock_type, lock_mode, lock_data, lock_status from performance_schema.data_locks;

we get an S-lock explosion

+-------------+------------+-----------+---------------+------------------------+-------------+
| object_name | index_name | lock_type | lock_mode     | lock_data              | lock_status |
+-------------+------------+-----------+---------------+------------------------+-------------+
| c           | NULL       | TABLE     | IX            | NULL                   | GRANTED     |
| c           | id         | RECORD    | X,REC_NOT_GAP | 8                      | GRANTED     |
| c           | parent     | RECORD    | S             | supremum pseudo-record | GRANTED     |
| c           | id         | RECORD    | S,REC_NOT_GAP | 3                      | GRANTED     |
| c           | parent     | RECORD    | S,GAP         | 3, 9                   | GRANTED     |
+-------------+------------+-----------+---------------+------------------------+-------------+

I get why the S-locks are necessary. I would have expected them to happen at the SELECT FOR UPDATE, though.
Instead they only happen later on the UPDATE.

• Why is that?
• Is that not a possible source for deadlocks?
• Why do they not happen on SELECT FOR UPDATE?

SELECT ... FOR UPDATE sets an intention exclusive lock (IX) on table level and exclusive lock (X) on row level (your table 1). Until you not UPDATE it is not known which gaps and next keys have to be locked additional to the already exclusive locked row identified by its id. The S locks are only required because you UPDATE the PK column and you have a FKC between parent and id.