并发执行Create/Select语句触发死锁问题排查及索引优化咨询

咱们先拆解下你遇到的死锁核心问题：你的Things表目前只有主键索引和指向ThingTypes的外键索引，当30-40次并发执行涉及ThingTypeId和HourId的SQL时，数据库没办法快速定位目标行，只能做全表扫描。这种情况下，每个事务会持有大范围的锁（甚至表级锁），多个事务互相等待对方释放锁，自然就容易触发死锁。

直接给你结论：给ThingTypeId和HourId添加联合索引，完全能解决这个死锁问题，再结合你提到的「所有并发请求的{@thingTypeID and @hourID}是唯一的」这个前提，效果会更显著，原因如下：

• 联合索引(ThingTypeId, HourId)能让数据库直接定位到唯一的目标行，彻底避免全表扫描，锁的范围会从整个表缩小到单个索引行，不会再出现因为扫描无关行而持有不必要锁的情况。
• 因为每个并发请求的ThingTypeId+HourId组合都是唯一的，不同事务操作的是完全独立的行，不会出现多个事务争抢同一行锁的场景，从根源上消除了死锁的触发条件。

额外的优化建议 #

• 考虑把ThingTypeId和HourId设为唯一约束：既然这个组合本身是唯一的，创建唯一约束不仅能保证数据的唯一性，还会自动生成对应的联合索引，比单独建索引更规范。
• 查看死锁日志验证：如果你的数据库支持（比如SQL Server的扩展事件、MySQL的SHOW ENGINE INNODB STATUS），可以查看死锁的详细日志，确认死锁确实是全表扫描导致的锁冲突，这样添加索引后就能精准验证解决效果。
• 缩短事务时长：尽量把事务控制在最小范围内，不要在事务里做无关的IO操作或业务逻辑，减少锁的持有时间，进一步降低冲突概率。

内容的提问来源于stack exchange，提问作者David Work