MySQL-存储引擎及基准测试

MySQL通常分为三层架构，第一层用于处理基于网络的客户端/服务器的工具或者服务都有的基础处理-连接处理、授权认证、安全；第二层用于查询解析、分析、优化、缓存以及所有的内置函数，所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图；第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。服务器通过API与存储引擎进行通信。这些接口屏蔽了不同引擎之间的差异，使得这些差异对上层的查询过程透明。

连接管理与安全性

每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责缓存线程，因此不需要为每个新建的连接创建或者销毁线程。

事务

事务是指一组原子性的SQL查询，或者一个独立的工作单元。
一个良好的事务处理系统具备如下特征：
原子性（atomicity):一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么提交成功，要么全部失败滚回。对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性。
一致性(constitency):数据库总是从一个一致性的状态转到另一个一致性的状态。
隔离性（isolation):一个事务所做的修改在最终提交以前，对其他事务是不可见的。
持久性(durability):一旦事务提交，所做的修改就会永久保存到数据库。

隔离级别

READ UNCOMMITED：事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读。
READ COMMITED:大多数数据库系统的默认级别是READ COMMITTED(但MySQL不是）。READ COMMITTED满足前面提到的隔离性的简单定义：一个事务开始时，只能看见已经提交的事务所做的修改。
REPEATABLE READ:解决了脏读的问题、该级别保证了在同一个事务中多次读取同样记录的结果是一致的。该级别存在另一个问题-幻读，指当某个事物在读取某个范围内的记录时，会产生幻行。
SERIALIZABLE:是最高的级隔离级别。通过强制事物串行，避免了前面说的幻读的问题。

死锁

死锁产生的原因：有些原因是真正的数据冲突，这种情况通常很难避免，有些则是由于存储引擎的实现方式导致的。

Mysql中的存储引擎

InnoDB、Archive、blackhole、CSV、Federated、memory、Merge、NDB Clster以及第三方存储引擎XtraDB和PBXT。

引擎的特点：
自动提交（AUTOCOMMIT)：MySQL默认模式。通过设置AUTOCOMMIT变量来启动或者禁用自动提交模式；
AUTOCOMMIT为1表示启动，0表示禁用。

多版本并发控制

SELECT
InnoDB会根据以下两个条件检查每行记录：
InnoDB只查找版本遭遇当前事务版本的数据行，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
行的删除版本要么未定义，要么大于当前事务版本号。这样可以确保事务读取到的行，在事务开始之前未被删除。
INSERT
InnoDB为新插入的每一行保存当前系统版本好。
DELETE
ＩｎｎｏＤＢ为删除的二米一行保存当前系统版本号作为行版本号。
UPDATE
ＩｎｎｏＤＢ为插入一行新纪录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

ＭｙＩＳＡＭ

具有全文索引、压缩、空间函数等特点，但是不支持事务或行级锁，而且有一个缺陷就是崩溃后无法安全恢复。

就准测试(benchmark)

针对系统设计的一种压力测试。为了掌握系统的行为。
应用场景：
验证基于系统的一些假设，确认这些假设是否符合实际情况。
重现系统中的某些异常行为，以解决这些异常。
测试系统当前的运行情况。
模拟比当前系统更高的负载，以便找出系统随着压力增加而可能遇到的扩展性瓶颈。
规划未来的业务增长。
测试应用适应可变环境的能力。
测试不同的硬件、软件和操作配置。
证明新采购的设备是否配置正确。

基准测试的策略

集成式（full-stack）和单组件（single-component)
集成式测试场景：
测试整个应用系统，包括web服务器、应用代码、网络和数据库；
MySQL并非总是应用的瓶颈，通过整体测试可以揭示这个问题；
只有针对整体测试，才能发现各部分之间的缓存带来的影响；
整体应员工的集成式测试更能揭示应员工的真实表现。
单组件测试应用场景：
需要比较不同的schema或者查询的性能。
针对应用中某个具体问题的测试；
为了避免漫长的基准测试，可以通过短期的基准测试。

测试指标

吞吐量、响应时间或者延迟、并发性（正在进行的并发操作，或者同时工作中的线程数或连接数，同时处理事务的能力）、可扩展性。

基准测试方法

进行基准测试之前应避免如下如问题:
使用真实数据的子集而不是全集。
使用错误的数据分布；
使用不真实的分布参数；
在多用户场景中，只做单用户的测试；
在单服务器上测试分布式应用；
与真实用户行为不匹配；
反复执行同一个查询；
没有检查错误；
忽略了系统预热的过程；
使用默认的服务器配置；
测试时间太短。

基准测试工具

集成式测试工具：
ab是一个appache HTTP服务器基准测试工具。测试服务器每秒最多可以处理请求数量。
http-load用作web服务器测试，可以通过一个输入文件提供多个URL，工具在这些URL中随机选择进行测试。
JMeter是一个Java应用程序，可以加载其他应用并测试其性能。通常被用于测试Web应用。
单组件测试工具：
mysqlslap：用于模拟服务器的负载，并输出计时信息。
MySQL Benchmark Suite：MySQL提供的基准测试套件，可以用在不同数据库服务器上进行比较测试。
Super Smack:用于MySQL和postgreSQL的基准测试工具，可以提供压力测试和负载生成。
Database Test Suite：由开源软件开发实验室（OSDL）设计，类似于某些工业标准测试的测试工具集。
Percona’s TPCC-MySQl Tool：类似于TPC-C的基准工具集。
sysbench：多线程系统压力测试工具。它可以根据影响数据库服务器性能的各种因素来评估系统的性能。

sysbench的文件I/O基准测试

准备阶段：生成测试用到的数据文件，生成的数据文件至少要比内存大。如果文件中的数据能完全放入内存中，则操作系统缓存大部分的数据，导致测试结果无法体现I/O密集型的工作负载。通过下面的命令创建一个数据集：

sysbench --test=fileio --file-total-size=150G prepare

运行阶段：针对不同的I/O类型有不同的测试选项：
seqwr:顺序写入
seqrewr:顺序重写
seqrd:顺序读取
rndrd：随机读取
rndwr:随机写入
rndnrw:混合随机读/写
sysbench --test=fileio --file-total-size150G --file-test-mode=rndrw/ --init-rng=on --max-time=300 --max-requests=0 run
测试完成之后清除生成的测试文件：
sysbench --test=fileio --file-total-sze=150G cleanup

sysbench的OLTP基准测试

生成数据表：
sysbench --test=oltp --oltp-table=1000000 --mysql-db=test/ --mysql-user=root prepare
执行测试：
sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run

其他sysbench特性

内存、线程、互斥锁、顺序写等