迫于开源社区、团体（Google Facebook Percona Xaprb等）的巨大压力，InnoDB Plugin相比Built-in版本有了很大的提升，这些提升多数来自开源社区贡献的代码，虽然本身也有一些改进。

1. 关于Fast locking

在多个线程并发访问相同资源的时候，需要使用一些InnoDB实现的互斥量（mutex）和读写锁（read/write lock）。在Unix-like平台上，InnoDB是通过Pthread的互斥量（这是POSIX标准的一部分）来实现的。在现代OS和硬件平台中，一般都有了更有效的替代方案，多数情况下这些替代方案使用更少的CPU指令和时钟周期来完成这些互斥处理。

从InnoDB1.0.3开始，如果你使用的GCC版本高于4.12，那么互斥量（mutex）和读写锁（read/write lock）可以通过GCC内置的atomic_memory_access功能来实现；如果你是在Solaris 10上，还可以通过系统自带的atomic_operations功能来实现互斥量（mutex）和读写锁（read/write lock）。

在编译时，InnoDB如果检测到了GCC的atomic_memory_access则会使用该功能，否则如果检测到有Solaris 10的atomic_operations，则会使用该功能。如果，上面条件都不满足，则会使用InnoDB使用POSIX Pthread实现的InnoDB互斥量（mutex）和读写锁（read/write lock）。

所以，这个特性不需要我们做任何配置。在InnoDB启动的时候，会在错误日志打印相关信息。如果InnoDB使用POSIX Pthread实现互斥量和读写锁将打印如下信息：

InnoDB: Mutexes and rw_locks use InnoDB’s own implementation

如果使用GCC的atomic memory access特性：

InnoDB: Mutexes and rw_locks use GCC atomic builtins

2. 关于内存分配

在InnoDB刚刚被开发的时候，当时多核CPU还并不是这么流行，当时也并没有针对多核CPU优化的内存分配器（memory allocator libraries ），所以InnoDB实现了一个自己的内存分配子系统（mem subsystem），这个子系统是通过单个互斥量（mutex）实现管理的，而这可能是一个瓶颈。除此，InnoDB还对OS自带的内存分配管理（malloc和free）作了一次简单封装，这些管理函数实现也类似地通过互斥量的机制实现的，所以这并没有解决问题。现在多核CPU到处都是（个人PC都是），现在也有了新的内存分配器，大大提升了对多核CPU的支持。例如： Hoard, libumem, mtmalloc, ptmalloc, tbbmalloc, and TCMalloc等等，如果你的应用有大量的内存分配和释放操作，使用这些内存分配器将对性能有很大的提升。

可以通过参数innodb_use_sys_malloc来控制InnoDB_Plugin是否使用系统的内存分配器。innodb_use_sys_malloc设置成0，InnoDB将使用自己实现的内存管理功能；设置为ON时（默认设置），则使用系统的内存分配器。这时如果系统中安装了新的内存分配器（如TCMalloc），只需在启动MySQL时，设定环境变量LD_PRELOAD和LD_LIBRARY_PATH指向新分配的动态连接库就可以了。