Go语言使用gorm对MySQL进行性能测试

之前写过了Go语言gorm框架MySQL实践，其中对gorm框架在 *** 作MySQL的各种基础实践，下面分享一下如何使用gorm框架对MySQL直接进行性能测试的简单实践。

这里我使用了一个原始的Go语言版本的 FunTester 测试框架，现在只有一个基本的方法，实在是因为Go语言特性太强了。框架设计的主要思路之一就是利用Go语言的闭包和方法参数特性，将一个 func() 当做性能测试的主题，通过不断运行这个 func() 来实现性能测试。当然还有另外一个思路就是运行一个多线程任务类，类似 Java 版本的 com.funtester.base.constaint.ThreadBase 抽象类，这样可以设置一些类的属性，绑定一些测试资源，适配更多的测试场景。

下面演示select的性能测试，这里我用了随机ID查询的场景。

这里我使用从35开始递增的ID进行删除。

这里使用了select的用例部分，随机ID，然后更新name字段，随机10个长度的字符串。

这里用到了 FunTester 字段都是随机生成。

到这里可以看出，性能测试框架用到的都是gorm框架的基础API使用，这里MySQL连接池的管理工作完全交给了gorm框架完成，看资料说非常牛逼，我们只需要设置几个参数。这个使用体现很像 HttpClient 设置 HTTP 连接池类似，这里我们也可以看出这些优秀的框架使用起来都是非常简单的。

PS：关于gorm的基础使用的请参考上一期的文章Go语言gorm框架MySQL实践。

　有一些有用的工具可以测试MySQL 和基于MySQL 的系统的性能。这里将演示如何利用这些工具进行测试。

mysqlslap

mysqlslap可以模拟服务器的负载，并输出计时信息。它包含在MySQL 5.1 的发行包中，应该在MySQL 4.1或者更新的版本中都可以使用。测试时可以执行并发连接数，并指定SQL 语句（可以在命令行上执行，也可以把SQL 语句写入到参数文件中）。如果没有指定SQL 语句，mysqlslap 会自动生成查询schema 的SELECT 语句。

MySQL Benchmark Suite （sql-bench）

在MySQL 的发行包中也提供了一款自己的基准测试套件，可以用于在不同数据库服务器上进行比较测试。它是单线程的，主要用于测试服务器执行查询的速度。结果会显示哪种类型的 *** 作在服务器上执行得更快。

这个测试套件的主要好处是包含了大量预定义的测试，容易使用，所以可以很轻松地用于比较不同存储引擎或者不同配置的性能测试。其也可以用于高层次测试，比较两个服务器的总体性能。当然也可以只执行预定义测试的子集（例如只测试UPDATE 的性能）。这些测试大部分是CPU 密集型的，但也有些短时间的测试需要大量的磁盘I/O *** 作。

这个套件的最大缺点主要有：它是单用户模式的，测试的数据集很小且用户无法使用指定的数据，并且同一个测试多次运行的结果可能会相差很大。因为是单线程且串行执行的，所以无法测试多CPU 的能力，只能用于比较单CPU 服务器的性能差别。使用这个套件测试数据库服务器还需要Perl 和BDB 的支持，相关文档请参考.

Super Smack

Super Smack是一款用于MySQL 和PostgreSQL的基准测试工具，可以提供压力测试和负载生成。这是一个复杂而强大的工具，可以模拟多用户访问，可以加载测试数据到数据库，并支持使用随机数据填充测试表。测试定义在"smack"文件中，smack 文件使用一种简单的语法定义测试的客户端、表、查询等测试要素。

Database Test Suite

Database Test Suite 是由开源软件开发实验室（OSDL,Open Source DevelopmentLabs）设计的，发布在SourceForge 网站上，这是一款类似某些工业标准测试的测试工具集，例如由事务处理性能委员会（TPC,Transaction Processing Performance Council）制定的各种标准。特别值得一提的是，其中的dbt2 就是一款免费的TPC-C OLTP 测试工具（未认证）。之前本书作者经常使用该工具，不过现在已经使用自己研发的专用于MySQL 的测试工具替代了。

Percona's TPCC-MySQL Tool

我们开发了一个类似TPC-C 的基准测试工具集，其中有部分是专门为MySQL 测试开发的。在评估大压力下MySQL 的一些行为时，我们经常会利用这个工具进行测试（简单的测试，一般会采用sysbench 替代），在源码库中有一个简单的文档说明。

sysbench

sysbench是一款多线程系统压测工具。它可以根据影响数据库服务器性能的各种因素来评估系统的性能。例如，可以用来测试文件I/O、 *** 作系统调度器、内存分配和传输速度、POSIX 线程，以及数据库服务器等。sysbench 支持Lua 脚本语言，Lua 对于各种测试场景的设置可以非常灵活。sysbench 是我们非常喜欢的一种全能测试工具，支持MySQL、 *** 作系统和硬件的硬件测试。（节选自《高性能MySQL》）

本文死锁场景皆为工作中遇到（或同事遇到）并解决的死锁场景，写这篇文章的目的是整理和分享，欢迎指正和补充，本文死锁场景包括：

注 ：以下场景隔离级别均为默认的Repeatable Read；

前提 ：表 t_user 的 uid 字段创建了唯一索引，并拥有可更新字段age。

场景复现 ：

相应业务案例和解决方案 ：

该场景常见于事务中存在for循环更新某条记录的情况，死锁日志显示 lock_mode X locks rec but not gap waiting （即行锁而非间隙锁），解决方案：

表结构 :

场景复现 ：

首先查询表中目前存在的记录：

执行两个事务的 *** 作：

死锁原因分析 ：

解决方案 ：

t_user结构改造为：

场景复现 *** 作（几率不高） ：

假设存在以下数据 ：

死锁分析 ：

事务1 ：

① 锁住zone_id=1对应的间隙锁: zoneId in (1,2)

② 锁住索引zone_id=1对应的主键索引行锁id = [1,2]

③ 锁住uid=1对应的间隙锁: uid in (1, 2)

④ 锁住uid=1对应的主键索引行锁: id = [1, 3]

事务2 ：

① 锁住zone_id=2对应的间隙锁: zoneId in (1,2)

② 锁住索引zone_id=2对应的主键索引行锁id = [3,4]

③ 锁住uid=2对应的间隙锁: uid in (1, 2)

④ 锁住uid=2对应的主键索引行锁: id = [2, 4]

解决方案 ：创建联合索引，使执行计划只会用到一个索引。

测试表结构 :

场景复现 *** 作 ：

解决办法：尽量避免这种插入又回滚的场景。

避免死锁的原则：

---