MySQL的锁分析

首先,我就先假设读者们都是了解数据库隔离级别的人,对所谓的RR,RC,RU,Serializable都是耳熟能详的。 如果不明白,可以看看这几篇文章,写的都很清楚,详细。 数据库隔离级别 乐观锁和悲观锁 但是,知道了这些概念,我们怎么去优化我们的SQL语句呢。其实还有一小段路。 比如说,现在有这么两个SQL语句: select * from t1 where id = 10; delete from t1 where id = 10 MySQL会采用什么样的方式进行加锁处理,加什么样的锁? 某种情况下,这个问题可以这么回答: 对于SQL1,MySQL不进行加锁处理,因为有MVCC的存在。 对于SQL2,对id等于10的记录进行加锁处理(主键索引)。 但是,这个答案是有前提的,比如说,id是不是主键? 当前系统的隔离级别是什么? id上有没有索引? 抑或是SQL的执行计划是什么,全盘扫描还是索引扫描? 等等。。都是需要考虑的,没有这些前提,这个SQL的执行结果就无法预知。 我们就来假设几种情况: 1. id为主键,RC隔离级别 这个组合最简单,因为id主键,所以对于给定的 delete from t1 where d=10 语句, 我们只要给id=10的记录加上X锁即可。 2. id为二级索引,RC隔离级别 何为二级索引,我们都知道mysql中每个表都有一个聚簇索引(clustered index ), 除此之外的表上的每个非聚簇索引都是二级索引,又叫辅助索引(secondary indexes). 仅仅对于InnoDB来说,每个表都有一个特殊的索引称为聚集索引。 如果您的表上定义有主键,该主键索引是聚集索引。如果你不定义为您的表的主键时, MySQL取第一个唯一索引(unique)而且只含非空列(NOT NULL)作为主键, InnoDB使用它作为聚集索引。如果没有这样的列,InnoDB就自己产生一个这样的ID值, 它有六个字节,而且是隐藏的,使其作为聚簇索引。 聚簇索引主要是为了方便存储。。所以二级索引,是对聚簇索引的索引。…

有关Java的动态代理

很早之前就知道Java的代理,同时也在设计模式这本书中了解了代理模式。于是开始尝试基于Java原生特性进行动态代理。 代理的很大的一个好处就是解耦合,通过这种手段,可以使程序有很好的可读性,而且在模块化上有着更好的实现,其实在Spring框架中,他所使用的AOP,很大程度上也是基于动态代理的方式进行的。 对于我们自己编写的代理类,我们可以随意的进行字节码的操操作,方便我们进行字节码的增强。有关字节码的增强,我会在下一篇日志中进行详细的描述。 现在先说一个使用ClassLoader的代理模式的简单例子。 我们现在有一个接口。接口中的代码如下: 这边是我的实现类代码,如下: 这是我的主函数,同时也是执行代理的主要内容: 在这边主要需要详细说一下这个ProxyMain类,我们可以看到这边这个类实现了InvocationHandler接口,这主要是用来实现对代理的全部Something类的方法的调用。 这个Proxy主要使用了Java反射API,将一般的方法调用映射到SomethingImp接口中,由此类推。 但这样的简单的例子,也有许多简单的代码。使用这些字节操作类库也是同样的具有挑战性。代码量和复杂度是代理的两大特点。创建简单的代码十分的困难。但是这样的代理也没有提供在系统范围内指定执行点的功能。但是这一点正好是AOP解决办法的关键点。 面向切面编程正式希望有这么一种机制,将业务逻辑横向切分。从而达到代码复用等一系列的优点。 写这篇文章的目的,就是因为有些同学问我面向切面编程的好处,同时,如何进行字节码操作(关于这一点,我将在之后的日志中详细描述),在代码量比较小的项目中,面向切面的优势确实无法提现,不过面向接口编程的思想,确实得需要自己的领悟。 通过这样的代码编写,再不考虑性能的情况下,可以热替代代码,比如一些工具类,我们可以在调用时采用这样的方法进行编写。这样的好处就是,如果需要热替代代码,只需要将对应的class文件进行替换,即可。