best design pattern for graphql mutation on object property update?

For example I have data type like this:

type Student{
    id: ID!
    name: String
    studentNumber: String
    address: String
}
// all fields are nullable, and we may want to "clear" some fields

What is the best schema pattern for updateStudent mutation?

1. Full update:

updateStudent(id:ID!, student:StudentInput!)

The input will have all keys in Student required to be required in StudentInput. This way the update param is the "final state" we want the object to be

2. Partial update:

Same mutation schema as previous one, but the input types are all optional to allow partial updates. However the resolver implementation will look really ugly:

const {name, studentNumber, address} = args.student

if(!isUndefined(name)) ...
if(!isUndefined(studentNumber)) ...
if(!isUndefined(address)) ...

// or
if("name" in args.student) ...
if("studentNumber" in args.student) ...
if("address" in args.student) ...

3. Partial updates + one mutation per field

type Mutation{
  updateStudentName(id:ID!, name:String)
  updateStudentAddress(id:ID!, address:String)
  updateStudentNumber(id:ID!, number:String)
}

4. Partial updates + one mutation per field

type Mutation {
  updateStudent(id:ID!): UpdateStudentMutation!
}

type UpdateAccountMutation{
  name(name:String): Student
  address(address:String): Student
  studentNumber(studentNumber:String): Student
}

For 1 vs 2/3/4, it is the debate of "final state" or partial "fields to update"

For 2 vs 3/4, it is the debate of all updates in "one mutation node" or "multi mutation nodes". And is 3/4 too much hazard for clients to wright ql operations?

For 3 vs 4, it is the the debate of "every mutation in root" or "grouped mutation". Extra thoughts, if mutation nodes are running in serial, then does that only apply to the root mutation or all sub-nodes of root mutation?

4 also have advantage that I only need to ACL checks on the root level comparing to 3