Two workers each run SELECT ... FOR UPDATE SKIP LOCKED to claim the next pending job, and separately, a service on MySQL keeps hitting unexplained deadlocks under concurrent inserts into a range. Explain both mechanisms and how they relate.

FOR UPDATE SKIP LOCKED lets many workers pull from the same queue table concurrently with no coordination: each worker's SELECT ... FOR UPDATE SKIP LOCKED LIMIT 1 locks and claims the first row nobody else has already locked, silently skipping any row currently held by another worker instead of waiting for it — so no two workers ever claim the same job and none of them block each other. The unexplained MySQL deadlocks are a different, InnoDB-specific mechanism: at MySQL's default isolation level (repeatable read), a locking read or a write over a range of rows also takes gap locks on the empty space between existing rows, specifically to stop a phantom row being inserted into that range — and two transactions each inserting into a range the other has gap-locked can end up waiting on each other, producing a deadlock that has nothing to do with either transaction touching the same actual row.