I am experiencing a deadlock which I am not able to replicate experimentally.
I believe from my experiments I figured out how to solve it but I would like to learn the underlying principle

Here is the SQL Server provided graph of the lock. From the object ID you can infer, that both processes are trying to access the same table.

The Table looks like this. (I used a global temp table for testing)

CREATE TABLE ##tMyTable(
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Fk_1_Id] [int] NOT NULL,
    [Fk_2_Id] [int] NULL,
    [Fk_3_Id] [int] NULL,
    [Day] [date] NOT NULL,
    [Quantity] [decimal](19, 3) NOT NULL,
 CONSTRAINT [Pk_MyTable_Id] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

+ foreign key stuff. 

The columns with the prefix Fk_ are foreign keys.

There is also an index on the table:

CREATE NONCLUSTERED INDEX [Idx_IndexName] ON ##tMyTable
(
    [Fk_1_Id] ASC,
    [Fk_2_Id] ASC--,
    [Day] ASC,
    [Id] ASC
)
INCLUDE([Fk_3_Id],[Quantity]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

The aborted process was a delete statement:

delete from ##tMyTable where Fk_2_Id = 86416

The process which was allowed to live was an insert. (dates are german format).

insert into ##tMyTable (Fk_1_Id, Fk_2_Id, Day, Quantity) select Fk_1_Id, 86415, Day, Quantity from tOtherTableWithSimilarColumns where Fk_4_Id = 22 and Day >= '01.07.2024' and Day < '01.08.2024'

For testing I set up two sessions with the following code.

Begin transaction

Select @@SPID as FirstTransactionProcessID

Query I want to test

commit

If I execute the code without including commit the transactions are locking their resources and I can simulate the deadlock situation.

With exec sp_lock I can check locks afterwards.

Before starting I inserted the following into the table:

insert into ##tMyTable (Fk_1_Id, Fk_2_Id, Fk_3_Id, Tag, Menge)
Select 1, 1, NULL, '2024-01-01', 22.404

In session 1 I executed this:

insert into ##tMyTable (Fk_1_Id, Fk_2_Id, Fk_3_Id, Tag, Menge)
Select 2, 2, NULL, '2024-01-01', 22.404

And then in session 2 I executed this:

delete from ##tMyTable where Fk_2_Id = 1

The result was this:

spid 77 is the insert and spid 69 is the delete.

As you can see, the delete tries to get a U lock on a key but does not get it because the insert X locks the key. However, I expected to see the insert locking a page with an IX lock while the delete wants the same page for a U lock.

Question: What about my testsetup is wrong? Why am I getting different locks compared to my original deadlock? And why doesn’t the delete just put an IX lock on the key and operates on the level of the row? Two IX locks are compatible and the queries shouldn’t bother each other. They are aiming at different IDs after all and therefore different rows.

What seems to solve my problem: If I create an index that only includes Fk_2_Id there are no locking conflicts in my testsetup. However, I would like to avoid “fixing” something without understanding why my solution works.