随着数据库中数据量日益增多，不得进行分库分表，在分库后将数据分布到不同的数据库实例（甚至物理机器）上，以达到降低数据量，提供系统的处理能力，但是这种架构也带来其他问题，比如本文要讲解的跨库分页查询的

出现很多deadlock日志，日志中同时也打印出表名和MDL，是insert on duplicate key update语句造成的死锁。本文记录死锁分析过程～

0. 问题背景 在正式进入问题之前，我先简单描述一下背景。我司基于javaagent做了一套字节码插件平台。如果大家有了解过Skywalking的话，那基本上跟这个差不多，只不过我们这个字节码平台的特

1. 先说问题 我司搭建了一个类似于Skywalking的字节码插件平台。基本原理参考谈谈Java Intrumentation和相关应用 。 所以我们就编写了各种神奇的插件。其中就有一个使用Sent

一般的代码要求类型必须是确定的，这对可以被不同的类型复用的代码产生了极大的限制。 将类型声明为超类或接口可以在一定范围内实现代码的复用，但这也只是将限制范围扩到了超类及其子类或实现了接口的类，在一些情况下这个范围还是不能满足到我们，尤其java是单根继承的。我们希望的是“非特定…

在很多用户交互的场景中，经常有给用户提供数据排序的需求，排序的交互嘛，前端有各种插件和方案可以实现，问题出在如何保存用户的排序结果。 最常规的方案，就是将排序后的所有数据的顺序保存下来或依次重新排序赋值，在数据量小的情况下，这样做可以接受。一旦数据量成千上万，这个方案就比较扯淡…

大家如果是做后端开发的，想必都实现过列表查询的接口，当然有的查询条件很简单，一条 SQL 就搞定了，但有的查询条件极其复杂，再加上库表中设计的各种不合理，导致查询接口特别难写，然后加班什么的就不用说了（不知各位有没有这种感受呢~）。 下面以一个例子开始，这是某购物网站的搜索条件…

这些问题你都搞清楚了吗？相信看完这篇文章会有答案。 首先回答一下为什么要分库分表，答案很简单：数据库出现性能瓶颈。用大白话来说就是数据库快扛不住了。 在高并发场景下，大量请求都需要操作数据库，导致连接数不够了，请求处于阻塞状态。 如果数据库中存在一张上亿数据量的表，一条 SQL…

参数解析器是spring mvc中将请求上下文中的请求参数转化要被调用的请求方法的参数的参数值。 参数解析器的初始化是在Handler适配器中。 spring mvc默认的参数解析器有20