Em primeiro lugar, se você usar como padrão o mecanismo de armazenamento InnoDB do MySQL, não há como atualizar dados sem bloqueios de linha, exceto definir o nível de isolamento da transação para READ UNCOMMITTED executando
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
No entanto, não acho que o comportamento do banco de dados seja o que você espera, pois a leitura suja é permitida nesse caso. READ UNCOMMITTED raramente é útil na prática.
Para complementar a resposta do @Tim, é realmente uma boa ideia ter um índice exclusivo na coluna usada na cláusula where. No entanto, observe também que não há garantia absoluta de que o otimizador eventualmente escolherá tal plano de execução usando o índice criado. Pode funcionar ou não funcionar, dependendo do caso.
Para o seu caso, o que você pode fazer é dividir a transação longa em várias transações curtas. Em vez de atualizar milhões de linhas de uma só vez, seria melhor verificar apenas milhares de linhas de cada vez. Os bloqueios X são liberados quando cada transação curta é confirmada ou revertida, dando às atualizações simultâneas a oportunidade de prosseguir.
A propósito, presumo que seu lote tenha prioridade menor do que os outros processos online, portanto, pode ser agendado fora do horário de pico para minimizar ainda mais o impacto.
P.S. O bloqueio IX não está no registro em si, mas anexado ao objeto de tabela de maior granularidade. E mesmo com o nível de isolamento da transação REPEATABLE READ, não há bloqueio de intervalo quando a consulta usa um índice exclusivo.
