How to prevent LCK_M_IX waiting/locking on the following Delete and Insert queries
Your problem has a name of lock escalation. You can read more on this here: How to resolve blocking problems that are caused by lock escalation in SQL Server.


  By default, SQL Server will acquire the finest-grain lock possible, in
  order to attain the  greatest concurrency. In most cases, this means
  SQL Server will acquire row (RID or  KEY) locks. SQL Server can
  acquire hundreds or thousands of individual locks on data  in a single
  table without causing any problems. In some cases, however, if SQL
  Server  determines that a query will access a range of rows within a
  clustered index, it may instead acquire page locks. After all, if
  every row on a page is going to be accessed, it's  easier to manage a
  single page lock than dozens, or hundreds, of row locks. In other
  cases,  primarily when there is no usable index to help process a
  query, SQL Server may lock an  entire table right at the beginning of
  processing a query.


In your case I suspect there are some indexes on the table (this means that delete acquires locks on them too) or you do your deletes in one transaction (this means that all the locks are held until the end of the transaction). In this case this happens:


  SQL Server  will escalate locks when any individual session acquires
  more than 5,000 locks in a  single statement. In this case, there is
  no randomness in choosing which session will get  its locks escalated;
  it is the session that acquired the locks.


So you should get rid of the wrapping transaction if it exists, or decrease batch size to a smaller one, or disable lock escatation on this table:

alter table order_option
set ( lock_escalation = disable )



  Do you think lowering the delete batch to less than 5000, or removing
  the index would help? In the case of removing the index, wouldn't that
  slow the delete considerably?


You should not drop this index, it helps you with your delete.

You can try batches of 2000 rows, it should help.

I don't know the kind of queries that run against this table but it could make sense to have clustered index on update_time and PK as nonclustered