如何查看MySQL数据库的死锁信息

1. 使用终端或命令提示符登录到MySQL，输入命令：mysql -h xxxx.xxx.xxx -P 3306 -u username -p 

解释：xxxx.xxx.xxx是数据库IP地址，username是数据库用户名，输入命令后，会让你输入username对应的密码，就可以登录了

2. 如何查看MySQL数据库的死锁信息 

在MySQL客户端下输入命令： 

show engine innodb status \G 

3. 如何定位MySQL数据库的死锁信息 

在打印出来的信息中找到“LATEST DETECTED DEADLOCK”一节内容，看图中红线 

4. 如何分析日志，定位死锁原因 

看3里面的图，紫色划线部分 

分析： 

事务1，等待 

RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`，这个位置的X锁 

事务2，持有 

RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁 

事务2，等待这个地方的X锁 

理论上这个事务2是可以提交的不会，死锁，但是这个事务日志只打印最后一部分死锁，信息，这里面隐含的条件是，事务1也持有 

RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁，这样，事务2不能加X锁，同时事务1也不能加X锁，产生死锁。

这个应该是一种配置的问题，数据库访问组件，你看下google：http://www.google.com.hk/#q=The+issue+appears+to+be+in+the+mysql+configuration+-+not+django&hl=zh-CN&newwindow=1&safe=strict&prmd=ivns&source=lnms&ei=2YEVTu24N6XjmAXS9YEM&sa=X&oi=mode_link&ct=mode&cd=1&ved=0CDMQ_AUoAA&fp=a3a6d99a2d1b77d7&biw=1366&bih=553

因为你这个网站组建没搞过，mysql的配置应该不存在问题

从搜索的内容看，好像是其要读固定目录的socket文件，估计是你们放同一个主机上的原因：

http://www.directadmin.com/forum/showthread.php?t=35480

不一定需要自己开发。Shard层可以位于：

1、DAO层：一般需要自行开发，可以灵活定制

2、ORM层：比如guzz、Hibernate Shard

3、JDBC API层：比较难，有一个商业产品dbShards

4、应用服务器与数据库之间通过代理实现：MySQL Proxy、amoeba.....

一 背景

当数据库中的数据量越来越大时，不论是读还是写，压力都会变得越来越大。采用MySQL

Replication多master多slave方案，在上层做负载均衡，虽然能够一定程度上缓解压力。但是当一张表中的数据变得非常庞大时，压力还是

非常大的。试想，如果一张表中的数据量达到了千万甚至上亿级别的时候，不管是建索引，优化缓存等，都会面临巨大的性能压力。

二 定义

数据sharding，也称作数据切分，或分区。是指通过某种条件，把同一个数据库中的数据分散到多个数据库或多台机器上，以减小单台机器压力。

三 分类

数据分区根据切分规则，可以分为两类：

1、垂直切分

数据的垂直切分，也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”(表)组成，我们垂直的将这些“数据块”切开，然后将他们分散

到多台数据库主机上面。这样的切分方法就是一个垂直(纵向)的数据切分。以表为单位，把不同的表分散到不同的数据库或主机上。规则简单，实施方便，适合业

务之间耦合度低的系统。

Sharding详解" title="MySQL Sharding详解" height="373" width="553">

垂直切分的优点

(1)数据库的拆分简单明了，拆分规则明确

(2)应用程序模块清晰明确，整合容易

(3)数据维护方便易行，容易定位

垂直切分的缺点

(1)部分表关联无法在数据库级别完成，需要在程序中完成

(2)对于访问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求

(3)事务处理相对更为复杂

(4) 切分达到一定程度之后，扩展性会遇到限制

(5)过读切分可能会带来系统过渡复杂而难以维护。

2、水平切分

一般来说，简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中，每个表中包含一部分数据。以行为单位，将同一个表中的数据按照某种条件拆分到不同的数据库或主机上。相对复杂，适合单表巨大的系统。

Sharding详解" title="MySQL Sharding详解" height="372" width="553">

水平切分的优点

(1)表关联基本能够在数据库端全部完成

(2)不会存在某些超大型数据量和高负载的表遇到瓶颈的问题

(3)应用程序端整体架构改动相对较少

(4)事务处理相对简单

(5)只要切分规则能够定义好，基本上较难遇到扩展性限制

水平切分的缺点

(1)切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则

(2)后期数据的维护难度有所增加，人为手工定位数据更困难

(3)应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。

3、联合切分

实际的应用场景中，除了那些负载并不是太大，业务逻辑也相对较简单的系统可以通过上面两种切分方法之一来解决扩展性问题之外，恐怕其他大部分业务逻辑稍微

复杂一点，系统负载大一些的系统，都无法通过上面任何一种数据的切分方法来实现较好的扩展性，而需要将上述两种切分方法结合使用，不同的场景使用不同的切

分方法。

Sharding详解" title="MySQL Sharding详解" height="480" width="342">

联合切分的优点

(1)可以充分利用垂直切分和水平切分各自的优势而避免各自的缺陷

(2)让系统扩展性得到最大化提升

联合切分的缺点

(1)数据库系统架构比较复杂，维护难度更大

(2)应用程序架构也相对更复杂

四 实现方案

现在 Sharding 相关的软件实现其实不少，基于数据库层、DAO 层、不同语言下也都不乏案例。限于篇幅，此处只作一下简要的介绍。

1、 Mysql Proxy + HASCALE

一套比较有潜力的方案。其中MySQL Proxy 是用 Lua 脚本实现的，介于客户端与服务器端之间，扮演 Proxy

的角色，提供查询分析、失败接管、查询过滤、调整等功能。目前的 0.6 版本还做不到读、写分离。HSCALE 则是针对 MySQL Proxy 插件，也是用

Lua 实现的，对 Sharding 过程简化了许多。需要指出的是，MySQL Proxy 与 HSCALE

各自会带来一定的开销，但这个开销与集中式数据处理方式单条查询的开销还是要小的。

MySQLProxy是MySQL官方提供的一个数据库代理层产品，和MySQLServer一样，同样是一个基于GPL开源协议的开源产品。可用来监视、分析或者传输他们之间的通讯信息。他的灵活性允许你最大限度的使用它，目前具备的功能主要有连接路由，Query分析，Query过滤和修改，负载均衡，以及基本的HA机制等。

实际上，MySQLProxy本身并不具有上述所有的这些功能，而是提供了实现上述功能的基础。要实现这些功能，还需要通过我们自行编写LUA脚本来实现。

MySQLProxy实际上是在客户端请求与MySQLServer之间建立了一个连接池。所有客户端请求都是发向MySQLProxy，然后经由MySQLProxy进行相应的分析，判断出是读 *** 作还是写 *** 作，分发至对应的MySQLServer上。对于多节点Slave集群，也可以起做到负载均衡的效果。以下是MySQLProxy的基本架构图：

Sharding详解" title="MySQL Sharding详解" height="480" width="420">

通过上面的架构简图，我们可以很清晰的看出MySQLProxy在实际应用中所处的位置，以及能做的基本事情。关于MySQLProxy更为详细的实施细则在MySQL官方文档中有非常详细的介绍和示例，感兴趣的读者朋友可以直接从MySQL官方网站免费下载或者在线阅读，我这里就不累述浪费纸张了。

---