Всё у тебя в порядке.
Дальше уже можно только вылизывать.
На самом деле, так как ты не задаёшь никаких WHERE на #AcAsYMD при апдейте, то работает только scan, для не range доступа это самый лучший доступ. Возможно table scan здесь был бы даже предпочтительнее, потому что после нахождения индекса нужно ещё слазить в страницы данных и поменять значение list_id там. Попробуй принудительно сказать table scan. Или можно попробовать сделать кластерный индекс на (asset_id, list_id), соответственно, делая primary key не с кластерным индексом. Хотя не уверен, что это поможет. Тут простой table scan всё равно будет лучше. Тогда можно ещё в primary key добавить list_id. Короче говоря, поиграть с кластерным индексом.
Или если размеры таблицы не очень велики, то попробуй сделать primary key (asset_id, account_id, yyyymmdd) - может заджойнит, не гоняя nested loops.
Ещё это может помочь в том случае, если update выполняется путём последовательных delete/insert (что чаще всего). В 7.0, конечно, нет вроде бы проблем с блокировками при insertе, но всё-таки кластерный индекс определяет порядок физического размещения данных в таблице, и delete/insertы могут быстрее проезжать.
И ещё, когда у тебя insert идёт, то посмотри в каком порядке у тебя подаются значения, участвующие в кластерном индексе. Я бы сказал, что insert должен быть дольше, чем update однозначно.
Но вот что мне не нравится, так это begin tran в процедуре. Оно надо? Лучше не стОит, мне кажется. Вот не в этом ли проблема долгого апдейта? Не ждёт она у тебя ничего, а? Блокировочки посмотри.

2 mikosha
Кластерный индекс может быть уникальным и неуникальным, и наоборот. Уникальность здесь не при чём.