本文目录一览：
自动化测试需要学多久?
自动化测试需要学4到6个月。不同培训机构的培训时长可能会不一样，如果是零基础的学生，培训周期一般为4到6个月，培训课程从八个阶段循序渐进，分别是计算机基础、功能测试课程、Python编程和数据库、自动化测试课程、性能测试、MySQL加强、LoadRunner和就业指导。
自动化测试的原理
GUI自动化测试的原理通过软件模拟用户实际的鼠标和键盘操作，实现自动化执行和操作的过程。性能自动化测试的原理通过客户端模拟多个虚拟用户并发请求，来检验服务器的性能行为是否满足系统要求。自动化测试是为了确保项目可以正常上线，项目的主流程没有bug，而手工测试就是为了发现很多很多的bug。
MySQL 5.7中新增sys schema有什么好处
性能优化利器:剖析MySQL 5.7新特征 sys schema
导读：很多团队在评估合适的时机切换到 MySQL 5.7，本文是在高可用架构群的分享，介绍 MySQL 5.7 新的性能分析利器。
李春，现任科技 MySQL 负责人，高级 MySQL 数据库专家，从事 MySQL 开发和运维工作 8 年。在担任 MySQL 数据库 leader 期间，主要负责应用架构的优化和部署，实现了阿里巴巴 3 亿 产品 从 Oracle 小型机到 64 台 MySQL 的平滑迁移。专注于研究 MySQL 复制、高可用、分布式和运维自动化相关领域。在大规模、分布式 MySQL 集群管理、调优、快速定位和解决问题方面有丰富经验。管理超过 1400 台 MySQL 服务器，近 3000 个实例。完成 MySQL 自动装机系统、MySQL 标准化文档和操作手册、MySQL 自动规范性检查系统、MySQL 自动信息采集系统等标准化文档和自动化运维工具。
sys schema 由来
Performance schema 引入
Oracle 早就有了 v$ 等一系列方便诊断数据库性能的工具，MySQL DBA 只有羡慕嫉妒恨的份，但是 5.7 引入的 sys schema 缓解了这个问题，让我们可以通过 sys schema 一窥 MySQL 性能损耗，诊断 MySQL 的各种问题。
说到诊断 MySQL 性能问题，不得不提在 MySQL 5.5 引入的 performance_schema，最开始引入时，MySQL 的 performance_schema 性能消耗巨大，随着版本的更新和代码优化，5.7 的 performance_schema 对 MySQL 服务器额外的消耗越来越少，我们可以放心的打开 performance_shema 来收集 MySQL 数据库的性能损耗。Tarique Saleem 同学测试了一下 sys schema 对 CPU 和 IO的额外消耗，基本在 1% - 3% 之间，有兴趣的同学可以参考他的这篇 blog：
（CPU Bound, Sysbench Read Only Mode）
performance_schema 不仅由于他的性能消耗大著名，还由于其复杂难用而臭名昭著。5.7 上的 performance schema 已经有 87 张表了，每个表都是各种统计信息的罗列；另外，他的这些表和 information_schema 中的部分表也缠夹不清，让大家用得很不习惯。
sys schema VS performance schema VS information schema
现在 MySQL 在 5.7 又新增了sys schema，它和 performance_schema 和 information schema 到底是什么关系？
Information_schema 定位基本是 MySQL 元数据信息，比如：TABLES 记录了 MySQL 有哪些表，COLUMNS 记录了各个表有哪些列 。
performance_schema 记录了 MySQL 实时底层性能消耗情况，比如：events_waits_current 记录了 MySQL 各个线程当前在等待的 event。
虽然他们之间的这个定位区别并没有那么明显：比如，Information_schema 的 innodb_locks 就记录了 innodb 当前锁的信息，它并不是 MySQL 的元数据信息。sys schema 最开始是 MarkLeith 同学为了方便读取和诊断 MySQL 性能引入到 MySQL 的。所以 sys schema 定位应该是最清晰的：它包含一系列对象，这些对象能够辅助 DBA 和开发人员了解 performance schema 和 information_schema 采集的数据。
sys schema 包含了什么？
sys schema 包含一些对象，这些对象主要用于调优和故障分析。 包括：
将 performance schema 和 information schema 中的数据用更容易理解的方式来总结归纳出来的“视图”。
提供 performance schema 和 information schema 配置或者生成分析报告类似操作的“存储过程”
sys schema 本身不采集和存储什么信息，它只是为程序或者用户提供一个更加方便的诊断系统性能和排除故障的“接口”。也就是说，查询 performance schema 和 information schema 配置和提供格式化服务的“存储函数” 。
避免用户在 information schema 和 performance schema 中写各种复杂的查询来获得到底谁锁了谁，每个线程消耗的内存是多少 ( 视图 memory_by_thread_by_current_bytes )，每个 SQL 执行了多少次，大致的执行时间是多少（ 视图 statements_with_runtimes_in_95th_percentile ）等，这些 sys schema 都直接帮你写好，你只需要直接查询就好了。
编写了一些现成的存储过程，方便你：直接使用 diagnostics() 存储过程创建用于诊断当前服务器状态的报告；使用 ps_trace_thread() 存储过程创建对应线程的图形化（ .dot类型 ）性能数据。
编写了一些现成的存储函数，方便你：直接使用 ps_thread_account() 存储函数获得发起这个线程的用户，使用 ps_thread_trx_info() 来获得某线程当前事务或者历史执行过的语句（ JSON 格式返回 ）。
当然，你也可以在 sys schema 下增加自己用于诊断 MySQL 性能的“视图”、“存储过程”和“存储函数”。
sys schema 举例
怎么利用 sys schema 来定位问题和诊断数据库性能？这里简单举一个 innodb 行锁的例子来说明。
模拟行锁
拿一个实际的场景来说 sys schema 能够辅助我们分析当前数据库上哪个 session 被锁住了，并且提供“清理”锁的语句。我们模拟一个表的某一行被锁住的情况，假设表创建语句如下：
CREATE TABLE `test2` (
`id` int(11) NOT NULL,
`name` varchar(16) DEFAULT NULL,
`age` int(11) DEFAULT NULL,
`sex` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
有一条数据如下：
mysql select * from test2;
+----+---------+------+------+
| id | name | age | sex |
+----+---------+------+------+
| 2 | pickup1 | 1 | 1 |
+----+---------+------+------+
我们分别在 session 1 和 session 2 上同时操作这条数据，这样的话必然对同一行记录相互有锁死的情况，然后我们通过 session 3 来查看 sys schema 里面的 innodb_lock_waits，确定到底是谁锁了谁，怎么解锁？操作步骤如下：
通过 sys.innodb_lock_waits 查看 innodb 锁表情况
对应的在 session 3上查看到的记录：
mysql select * from sys.innodb_lock_waits\G
*************************** 1. row ***************************
wait_started: 2016-05-04 01:04:38
wait_age: 00:00:02
wait_age_secs: 2
locked_table: `test`.`test2`
locked_index: PRIMARY
locked_type: RECORD
waiting_trx_id: 5382
waiting_trx_started: 2016-05-04 00:24:21
waiting_trx_age: 00:40:19
waiting_trx_rows_locked: 4
waiting_trx_rows_modified: 0
waiting_pid: 3
waiting_query: update test2 set name='pickup3' where id=2
waiting_lock_id: 5382:31:3:3
waiting_lock_mode: X
blocking_trx_id: 5381
blocking_pid: 2
blocking_query: NULL
blocking_lock_id: 5381:31:3:3
blocking_lock_mode: X
blocking_trx_started: 2016-05-04 00:23:49
blocking_trx_age: 00:40:51
blocking_trx_rows_locked: 1
blocking_trx_rows_modified: 1
sql_kill_blocking_query: KILL QUERY 2
sql_kill_blocking_connection: KILL 2
这里我们可以看到 3 号线程（ waiting_pid: 3 ）在等待 2 号线程（ blocking_pid: 2 ）的 X 锁（ blocking_lock_mode: X ），如果需要解锁，需要杀掉 2 号线程（ sql_kill_blocking_connection: KILL 2 ）。
innodb_lock_waits 本质
其实 sys schema 的 innodb_lock_waits 只是 information schema 的视图而已。
CREATE ALGORITHM = TEMPTABLE DEFINER = `mysql.sys`@`localhost` SQL SECURITY INVOKER VIEW `innodb_lock_waits` AS
SELECT
`r`.`trx_wait_started` AS `wait_started`,
TIMEDIFF(NOW(),
`r`.`trx_wait_started`) AS `wait_age`,
TIMESTAMPDIFF(
SECOND,
`r`.`trx_wait_started`,
NOW()) AS `wait_age_secs`,
`rl`.`lock_table` AS `locked_table`,
`rl`.`lock_index` AS `locked_index`,
`rl`.`lock_type` AS `locked_type`,
`r`.`trx_id` AS `waiting_trx_id`,
`r`.`trx_started` AS `waiting_trx_started`,
TIMEDIFF(NOW(),
`r`.`trx_started`) AS `waiting_trx_age`,
`r`.`trx_rows_locked` AS `waiting_trx_rows_locked`,
`r`.`trx_rows_modified` AS `waiting_trx_rows_modified`,
`r`.`trx_mysql_thread_id` AS `waiting_pid`,
`sys`.`format_statement`(`r`.`trx_query`) AS `waiting_query`,
`rl`.`lock_id` AS `waiting_lock_id`,
`rl`.`lock_mode` AS `waiting_lock_mode`,
`b`.`trx_id` AS `blocking_trx_id`,
`b`.`trx_mysql_thread_id` AS `blocking_pid`,
`sys`.`format_statement`(`b`.`trx_query`) AS `blocking_query`,
`bl`.`lock_id` AS `blocking_lock_id`,
`bl`.`lock_mode` AS `blocking_lock_mode`,
`b`.`trx_started` AS `blocking_trx_started`,
TIMEDIFF(NOW(),
`b`.`trx_started`) AS `blocking_trx_age`,
`b`.`trx_rows_locked` AS `blocking_trx_rows_locked`,
`b`.`trx_rows_modified` AS `blocking_trx_rows_modified`,
CONCAT(
'KILL QUERY ',
`b`.`trx_mysql_thread_id`
) AS `sql_kill_blocking_query`,
CONCAT('KILL ',
`b`.`trx_mysql_thread_id`) AS `sql_kill_blocking_connection`
FROM
(
(
(
(
`information_schema`.`innodb_lock_waits` `w`
JOIN
`information_schema`.`innodb_trx` `b` ON((`b`.`trx_id` = `w`.`blocking_trx_id`))
)
JOIN
`information_schema`.`innodb_trx` `r` ON(
(`r`.`trx_id` = `w`.`requesting_trx_id`)
)
)
JOIN
`information_schema`.`innodb_locks` `bl` ON(
(
`bl`.`lock_id` = `w`.`blocking_lock_id`
)
)
)
JOIN
`information_schema`.`innodb_locks` `rl` ON(
(
`rl`.`lock_id` = `w`.`requested_lock_id`
)
)
)
ORDER BY
`r`.`trx_wait_started`
innodb_lock_waits和x\$innodb_lock_waits区别
有心的同学可能会注意到，sys schema 里面有 innodb_lock_waits 和 x\$innodb_lock_waits。 其实 sys schema 的这些视图大部分都成对出现，其中一个的名字除了 x\$ 前缀以外跟另外一个是一模一样的。例如，host_summmary_by_file_io 视图分析汇总的是根据主机汇总的文件 IO 情况，并将延迟从皮秒（ picoseconds ）转换成更加易读值（ 带单位 ）显示出来：
mysql SELECT * FROM host_summary_by_file_io;
+------------+-------+------------+
| host | ios | io_latency |
+------------+-------+------------+
| localhost | 67570 | 5.38 s |
| background | 3468 | 4.18 s |
+------------+-------+------------+
而 x\$host_summary_by_file_io 视图分析汇总的是同样的数据，但是显示的是未格式化过的皮秒（ picosecond ）延迟值
mysql SELECT * FROM x$host_summary_by_file_io;
+------------+-------+---------------+
| host | ios | io_latency |
+------------+-------+---------------+
| localhost | 67574 | 5380678125144 |
| background | 3474 | 4758696829416 |
+------------+-------+---------------+
没有 x\$ 前缀的视图是为了提供更加友好，对人更加易读的输出格式。带 x\$ 前缀的视图显示了数据原始格式，它方便其他工具基于这些数据进行自己的处理。需要了解非 x\$ 和 x\$ 视图的不同点的进一步信息。
QA
提问：sys schema 只是在 performance_schema 和 information_schema 之上创建视图和存储过程？
李春：对，sys schema 主要针对的其实是 iperformance schema，有部分 information schema 的表也会整理到 sys schema 中统一展现。
提问：运行 KILL 2 杀掉 2 线程？blocking_lock_mode: X 的 X 什么意思？
李春：blocking_lock_mode 的 X 是指 X 锁，exclusive 锁，排它锁，跟它对应的是 S 锁，共享锁。kill 2 是杀掉 2 号线程，这样可以将锁释放，让被锁的这个线程正常执行下去。
提问：可以放心的打开 performance_schema，为何不使用 performance_schema 再造一个 sys schema？
李春：performance schema 是 MySQL 采集数据库性能的存储空间。sys schema 其实只是对 performance schema 多个表 join 和整合。两者的定位有所不同，如果直接放在 performance schema 中，分不清哪些是基表，哪些是视图，会比较混淆。
提问：pt-query-digest 这些工具的有开始使用 sys schema 吗？
李春：没有，pt-query-digest 主要用于分析慢查和 tcpdump 的结果，跟 sys schema 的定位有部分重叠的地方，sys schema 会分析得更细，更内核，更偏底层一些，pt-query-digest 主要还是从慢查和 tcpdump 中抽取 SQL 来格式化展现。
提问：阿里这么多数据库实例，使用什么运维工具？分布式事务又是怎么解决的呢？
李春：阿里内部有非常多的运维工具，dbfree，idb 等，用于数据库资源池管理，数据库脱敏，开发测试库同步，数据库订正，表结构变更等。分布式事务主要通过业务上的修改去屏蔽掉，比如：电影买票并不是你选了座位和付款就必须在一个事务里面，抢票，选座，付款分别是自己的子事务，系统耦合性比较弱，相互通知解决问题。
提问：Oracle 有 v$，MySQL 有 x$ ？两个 $ 是完成相似功能的吗？
李春：MySQL 的 x$ 可以说是仿照 Oracle 的 v$ 来做的，但是目前离 Oracle 的那么强大的数据库诊断功能还有一些距离。
提问：数据库脱敏能否简单介绍下实现方式？
李春：开发测试人员无法访问线上数据库，需要通过一个专门的 idb 来访问，而 idb 系统每个字段都有密级定义，满足权限的才能被访问；这个系统页控制了用户是否可以访问某个表，可以访问数据表的行数，只有主管同意了，用户才能访问某个表的数据，并且加密数据是以*显示的。
mysql数据库性能测试
我理解的是你希望了解mysql性能测试的方法：
其实常用的一般：
选取最适用的字段属性
MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。
另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。
对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。
2、使用连接（JOIN）来代替子查询(Sub-Queries)
MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示：
DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询可以被更有效率的连接（JOIN）.. 替代。例如，假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：
SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
如果使用连接（JOIN）.. 来完成这个查询工作，速度将会快很多。尤其是当salesinfo表中对CustomerID建有索引的话，性能将会更好，查询如下：
SELECT * FROM customerinfo LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo. CustomerID WHERE salesinfo.CustomerID IS NULL
连接（JOIN）.. 之所以更有效率一些，是因为 MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。
3、使用联合(UNION)来代替手动创建的临时表
MySQL 从 4.0 的版本开始支持 UNION 查询，它可以把需要使用临时表的两条或更多的 SELECT 查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用 UNION 来创建查询的时候，我们只需要用 UNION作为关键字把多个 SELECT 语句连接起来就可以了，要注意的是所有 SELECT 语句中的字段数目要想同。下面的例子就演示了一个使用 UNION的查询。
SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM author
UNION
SELECT Name, Supplier FROM product
4、事务
尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。要避免这种情况，就应该使用事务，它的作用是：要么语句块中每条语句都操作成功，要么都失败。换句话说，就是可以保持数据库中数据的一致性和完整性。事物以BEGIN 关键字开始，COMMIT关键字结束。在这之间的一条SQL操作失败，那么，ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。
BEGIN;
INSERT INTO salesinfo SET CustomerID=14;
UPDATE inventory SET Quantity=11
WHERE item='book';
COMMIT;
事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。
5、锁定表
尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户
来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。
其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。
LOCK TABLE inventory WRITE
SELECT Quantity FROM inventory
WHEREItem='book';
...
UPDATE inventory SET Quantity=11
WHEREItem='book';
UNLOCK TABLES
这里，我们用一个 SELECT 语句取出初始数据，通过一些计算，用 UPDATE 语句将新值更新到表中。包含有 WRITE 关键字的 LOCK TABLE 语句可以保证在 UNLOCK TABLES 命令被执行之前，不会有其它的访问来对 inventory 进行插入、更新或者删除的操作。
6、使用外键
锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。例如，外键可以保证每一条销售记录都指向某一个存在的客户。在这里，外键可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到salesinfo中。
CREATE TABLE customerinfo
(
CustomerID INT NOT NULL ,
PRIMARY KEY ( CustomerID )
) TYPE = INNODB;
CREATE TABLE salesinfo
(
SalesID INT NOT NULL,
CustomerID INT NOT NULL,
PRIMARY KEY(CustomerID, SalesID),
FOREIGN KEY (CustomerID) REFERENCES customerinfo
(CustomerID) ON DELETECASCADE
) TYPE = INNODB;
注意例子中的参数“ON DELETE CASCADE”。该参数保证当 customerinfo 表中的一条客户记录被删除的时候，salesinfo 表中所有与该客户相关的记录也会被自动删除。如果要在 MySQL 中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表 InnoDB类型。该类型不是 MySQL 表的默认类型。定义的方法是在 CREATE TABLE 语句中加上 TYPE=INNODB。如例中所示。
7、使用索引
索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(), MIN()和ORDERBY这些命令的时候，性能提高更为明显。那该对哪些字段建立索引呢？一般说来，索引应建立在那些将用于JOIN, WHERE判断和ORDER BY排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况，例如customerinfo中的“province”.. 字段，在这样的字段上建立索引将不会有什么帮助；相反，还有可能降低数据库的性能。我们在创建表的时候可以同时创建合适的索引，也可以使用ALTER TABLE或CREATE INDEX在以后创建索引。此外，MySQL
从版本3.23.23开始支持全文索引和搜索。全文索引在MySQL 中是一个FULLTEXT类型索引，但仅能用于MyISAM 类型的表。对于一个大的数据库，将数据装载到一个没有FULLTEXT索引的表中，然后再使用ALTER TABLE或CREATE INDEX创建索引，将是非常快的。但如果将数据装载到一个已经有FULLTEXT索引的表中，执行过程将会非常慢。
8、优化的查询语句
绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。下面是应该注意的几个方面。首先，最好是在相同类型的字段间进行比较的操作。在MySQL 3.23版之前，这甚至是一个必须的条件。例如不能将一个建有索引的INT字段和BIGINT字段进行比较；但是作为特殊的情况，在CHAR类型的字段和VARCHAR类型字段的字段大小相同的时候，可以将它们进行比较。其次，在建有索引的字段上尽量不要使用函数进行操作。
例如，在一个DATE类型的字段上使用YEAE()函数时，将会使索引不能发挥应有的作用。所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。
SELECT * FROM order WHERE YEAR(OrderDate)2001;
SELECT * FROM order WHERE OrderDate"2001-01-01";
同样的情形也会发生在对数值型字段进行计算的时候：
SELECT * FROM inventory WHERE Amount/724;
SELECT * FROM inventory WHERE Amount24*7;
上面的两个查询也是返回相同的结果，但后面的查询将比前面的一个快很多。第三，在搜索字符型字段时，我们有时会使用 LIKE 关键字和通配符，这种做法虽然简单，但却也是以牺牲系统性能为代价的。例如下面的查询将会比较表中的每一条记录。
SELECT * FROM books
WHERE name like "MySQL%"
但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：
SELECT * FROM books
WHERE name="MySQL"and name"MySQM"
最后，应该注意避免在查询中让MySQL进行自动类型转换，因为转换过程也会使索引变得不起作用。
