What problems can be with RESTRICT foreign keys?

Question

MySQL

1. Looked at the migrations of different projects on github and basically put CASCADE and sometimes SET NULL. RESTRICT is very rare, while they put relationships on primary keys, fields that probably never change. I have all the logic of relationships in my application, for safety reasons I decided to put foreign keys, but I don’t see the point of putting CASCADE on primary keys, I think there are high chances that someone accidentally (through PMA, etc.) is trying to change this value, and I just have to say no to him. Or is it not?
2. Does it make sense to put foreign keys on optional fields, for example, the user id that updated / created the record, etc.
3. Does it make sense to lock tables during migrations? Or should a transaction suffice?

Answer 1

restrict is default by the sql standard. And the most optimal for the task of "preventing doing stupid things."
FK should be put on all connections. Unless clearly and convincingly proven otherwise for each specific case individually.
MySQL? All DDLs are not only non-transactional, but also cause an implicit commit.
Whether you need to explicitly lock tables depends on what you're going to do. Usually the task is how to make a change without affecting the prod.