mysql 存储过程捕获所有的异常
MySQL数据库如何删除重复数据？
MySQL数据库如何删除重复数据？
现在数据库有几万条数据，如何删除重复数据只留下一条就行，
比如，有十条一样的数据，要删除掉其他九条记录，只留下一条就行
楼主的问题是如何删除重复数据仅保留其中一条，接下来就介绍一下如何实现该需求。
数据准备示例表 Student_Information 如下 ：
我们插入一部分数据到该表，其中存在多条姓名为 Anaa 的手机号码重复数据，如下：
入库后数据如下：
设计删除SQL我们通过Group by对手机号进行分组，然后计算每组最大ID作为保留数据，然后删除其他数据。SQL设计如下：
执行该SQL，结果如下:
我们可以看到，该SQL删除了重复的数据时，并且保留了id最大的数据（最新数据）。
设计该SQL时需要注意什么？
我们需要注意，使用 MySQL 进行 Delete From 操作时，若子查询的 FROM 字句和更新、删除对象使用同一张表时，会出现You cant specify target table for update in FROM clause”。错误。
比如，我们设计如下SQL，该SQL从语法来看也是实现删除 Student_Information 表重复数据，我们执行一下看下结果。
执行结果如下，我们可以看到抛出了You cant specify target table for update in FROM clause”错误，那么该如何解决呢？
解决这个问题的方法也很简单，就是将 select 出的结果通过中间表再 select 一遍即可，如下：
mysql命令运行不了？
mysql执行不了，首先检查一下，是不是服务器连接错误，如果服务器连接错误的话，确实是没有反应的，然后再去检查自己的sql脚本有没有问题，from后引用的表有没有写错，如果检查过后还是不行的话，可以去咨询数据库管理员，自己的权限有问题，还是数据库除了问题。
详解mysql数据库死锁如何打印到错误日志及死锁实验测试？
死锁的概念
死锁：死锁一般是事务相互等待对方资源，最后形成环路造成的。
对于死锁，数据库处理方法：牺牲一个连接，保证另外一个连接成功执行。
发生死锁会返回ERROR：1213 错误提示，大部分的死锁InnoDB存储引擎本身可以侦测到，不需要人为进行干预。
注意：
InnoDB存储引擎并不会回滚大部分的错误异常，像阻塞章节里面的例子，但是死锁例外，发现死锁后，InnoDB存储引擎会马上回滚一个事务，会返回1213错误。
死锁的情形举例
eg1：
mysql死锁以及死锁日志分析
mysql死锁以及死锁日志分析
mysql死锁以及死锁日志分析
分析死锁日志：
第一部分
从日志里我们可以看到事务1当前正在执行update info_users set mobile18514656666 where mobile18514656620，该条语句正在申请表info_users的索引IDX_MOBILE的X锁，所以提示lock_mode X waiting
第二部分：
然后日志的下半部分说明了事务2当前‘持有的锁’以及‘等待的锁’：
从日志的HOLDS THE LOCKS(S)块中我们可以看到事务2持有索引IDX_MOBILE的X锁，并且是记录锁（Record Lock）。该锁是通过事务2在步骤2执行的update语句申请的。
从日志的WAITING FOR THIS LOCK TO BE GRANTED块中我们可以看到事务2正在申请持有表info_area的索引GEN_CLUST_INDEX的X锁，该锁是delete from info_area where id1语句申请的。
eg2：
mysql死锁以及死锁日志分析
eg3：
mysql死锁以及死锁日志分析
mysql死锁以及死锁日志分析
mysql死锁以及死锁日志分析
分析死锁日志：
第一部分
从日志里我们可以看到事务1当前正在执行DELETE from users where uidbbb，该条语句正在申请索引UID的X锁，所以提示lock_mode X waiting
第二部分：
然后日志的下半部分说明了事务2当前‘持有的锁’以及‘等待的锁’：
从日志的HOLDS THE LOCKS(S)块中我们可以看到事务2持有索引UID的X锁，并且是记录锁（Record Lock）。该锁是通过事务2在步骤2执行的delete语句申请的。
从日志的WAITING FOR THIS LOCK TO BE GRANTED块中我们可以看到事务2正在申请持有索引UID的S锁，该锁是insert INTO users VALUES(2,bbb)语句申请的。insert语句在普通情况下是会申请X锁，但是这里出现了S锁。这是因为uid字段是一个索引，所以insert语句会在插入前进行一次duplicate key的检查，为了使这次检查成功，需要申请S锁防止其他事务对uid字段进行修改。
那么为什么该S锁会失败呢？这是对同一个字段的锁的申请是需要排队的。S锁前面还有一个未申请成功的X锁，所以S锁必须等待，所以形成了循环等待，死锁出现了。
通过阅读死锁日志，我们可以清楚地知道两个事务形成了怎样的循环等待，再加以分析，就可以逆向推断出循环等待的成因，也就是死锁形成的原因。