Правильно заданный вопрос содержит половину ответа
Если нет проблем с производительностью - то зачем тогда ставить задачу "быстро обработать все записи"?
Многопоточка да, очевидно, имеет сложности в отладке, но отлаживать ее можно и в одном потоке.
А вот с фразой, что многопоточка - "прямой путь к проблемам с локами на таблицах" категорически не согласен. Просто методики программирования под многопоточку должны быть несколько иными, нежели обычное программирование.
Во-первых, для многопоточки нужно четкое секционирование объема данных для каждого потока. С учетом понимания, что накладные расходы на запуск и завершение потока должны быть ничтожно малы по отношению к времени работы потока. Т.е. условно - на каждый поток есть смысл планировать не меньше 1000-5000 записей (цифры условные - точные цифры покажет время; реализовав многопоточку - нужно добавлять параметры, регулирующие количество потоков и объем данных потока чтобы получить оптимальную скорость)
Во-вторых, это четкое секционирование необходимо обеспечить кластерным индексом (а лучше, чтобы этот кластерный индекс еще был бы и уникальным)
В-третьих, нужно гарантировать, что 2 разных потока не будут пытаться выбрать на обновление одну и ту же запись (пусть даже в другой таблице).
Ну и надо понимать, что технически разработка многопточки (или под многопоточку, когда уже есть какая-то база) - всяко сложнее, нежели обычная обработка.
В общем, пожалуй - самое важное - это деление данных + оценка "стоит ли игра свеч".
Для понимания: Если надо по-быстрому перелопатить 24 млн записей - это один расклад. Если речь идет об объеме 1-2 млн записей - то смысле нет.