1) В целом нет. SELECT в общем случае всегда быстрее и предпочтительнее UPDATE.
2) Зависит в т.ч. от количества сессий, и что клиенты делают. Если у вас к БД обращаются тысячи пользователей, которые забирают/обновляют/добавляют данные в эту таблицу и связанные с ней, то что произойдет когда вы решите обновить данные в миллионе записей - вопрос. Хорошего вряд ли. Если к БД обращается 1.5 клиента в час, то можно попробовать. Но судя по тому, что у вас 100 млн. операций, их кто-то должен производить в таком количестве.

Создайте тестовую БД, сделайте прикидочные прогоны и посмотрите на результат. Потому что он может быть как приемлемым в конкретном случае, так и неприемлемым - уравнение со многими неизвестными. Если что, можно поднять аппаратные ресурсы, подумать над оптимизацией архитектуры. Возможно имеет смысл разделить данные по нескольким таблицам. Например, на текущие и (условно) архивные. Или, например, по видам операций. Тогда у вас появится возможность манёвра между 100 млн. записей. Но это я фантазирую, что у вас за проект неизвестно и каких параметров быстродействия вы хотите достичь тоже.