RDBMS performance on updating an index key(non primary)

Question

I am creating a scheduler service for which I am using RDBMS(Mariadb, engine:InnoDB), which has following schema for jobs table

CREATE TABLE `jobs` (
  `id` bigint(11) unsigned NOT NULL AUTO_INCREMENT,
  `job_id` char(63) NOT NULL DEFAULT '',
  `eta` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
  `state` char(31) NOT NULL DEFAULT '',
  `attempts` tinyint(4) NOT NULL,
  `retrial_streategy` char(31) NOT NULL DEFAULT '',
  `payload` text DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `eta_state` (`eta`,`state`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

You can see an index with composite key (eta, state), which I want to use for bulk finding jobs that has passed now timestamp and having state as scheduled.

1. I want to expose an API to update the eta column, if client want to postpone it.
2. If an attempt fails, I will need to reschedule it to a later timestamp depending on strategy. So again the ETA is needed to be changed.

And both of these updates are very probable to happen like 50% rows will require update before successful completion. These updates will happen one row at a time, selected using job_id, and independently.

I want to know how will updating an indexed column will perform?

If this is not expected to perform well, then is there a workaround?

(from Comment)

1. Basically the rows will not be updated in bulk but one at a time randomly, to clear further update the job's eta with job_id. job_id is unique key.
2. No, update eta will happen in two states. These are SCHEDULED and IN_PROGRESS. A job that has not yet started execution(i.e. SCHEDULED state) can be updated by client with new ETA. A job that fails to execute(i.e currently. IN_PROGRESS state), will be updated with new ETA and state SCHEDULED.

Answer 1

Even without an INDEX, updating 50% of the rows is a long process.

Will they be updated one row at a time? Or will it use a WHERE clause to specify the 50%?

If the new eta belongs to all of one state, then it should not be in this table but a much smaller table with perhaps only state and eta.

As a side issue: Use VARCHAR, not CHAR, for variable length columns.