死锁是指两个或者多个事务在同一资源上相互占用，井请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，就可能会产生死锁。
    多个事务同时锁定同一个资源时，也会产生死锁。例如，设想下面两个事务同时处理StockPrice 表：
    事务1

    1. START TRANSACTION;
    2. UPDATES tockPrice SET close= 45.50 WHEREst ock_id = 4 and date='2002-05-01';
    3. UPDATES tockPrice SET close= 19.80 WHEREst ock_id = 3 and date='2002-05-02';
    4. COMMIT;

    事务2

    START T.RANSACTION;
UPDATES tockPrice SET high = 20.12 WHEREst o亡k_id = 3 and date ='2002-05-02';
UPDATES tockPrice SET high = 47.20 WHEREst ock_id = 4 and date='2002-05-01';
COMMIT;

    如果凑巧，两个事务都执行了第一条UPDATE 语句，更新了一行数据，同时也锁定了该行数据，接着每个事务都尝试去执行第二条UPDATE 语句，却发现该行已经被对方锁定，然后两个事务都等待对方释放锁，同时又持有对方需要的锁，则陷入死循环。除非有外部因素介入才可能解除死锁。
    为了解决这种问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB 存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误。这种解决方式很有效，否则死锁会导致出现非常慢的查询。还有一种解决方式，就是当查询的时间达到锁等待超时的设定后放弃锁请求，这种方式通常来说不太好。InnoDB 目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。
    锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则完全是由于存储引擎的实现方式导致的。