You can create a trigger on a view. Here's the documentation.

Instead of a trigger, I'd suggest a design that let's you add jobs. What if they...

Certainly replacing the table variable with a temp table will likely lead to improvements as will the code that Chris is suggesting.

However, that doesn't explain why you're seeing...

Lots and lots of scans. Despite a large number of filters, you're getting scans all over the place. Ignoring the fact that you don't have clustered indexes, the indexes you...

Why not use Extended Events. You're on 2016. They're better and generally more accurate.

To get radical differences in behavior, something has to be different. Did you check the execution plans as I suggested? Are they different? If so, are the parameters that compiled...

Generally, just delete the data. It's the best approach. Sometimes, breaking the data into chunks can help. Here's an article to give you some ideas.

There is absolutely ZERO way to tune a query that is selecting all columns and all rows. You can't do it.

What you can do, is tune the hardware...

Sure, this kind of thing happens all the time. Have you compared execution plans, the one running fast the one running slowly? Are they the same? Probably not. What are...

When you create a stored procedure, it doesn't validate the existence of objects, just syntax. It's when you execute the code that you hit the problems. So yeah, CREATE or...

Honestly, a single shrink of the database, I wouldn't sweat it too much. It's repeated, even scheduled, shrinks that lead to all sorts of problems. One time, one shrink, no...