标签归档:InnoDB

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键

我们先了解下InnoDB引擎表的一些关键特征:

  • InnoDB引擎表是基于B+树的索引组织表(IOT);
  • 每个表都需要有一个聚集索引(clustered index);
  • 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree);
  • 基于聚集索引的增、删、改、查的效率相对是最高的;
  • 如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择其作为聚集索引;
  • 如果没有显式定义主键,则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引;
  • 如果也没有这样的唯一索引,则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增,这个ROWID不像ORACLE的ROWID那样可引用,是隐含的)。

综上总结,如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话,这时候存取效率是最高的,也就是下面这几种情况的存取效率最高:

  • 使用自增列(INT/BIGINT类型)做主键,这时候写入顺序是自增的,和B+数叶子节点分裂顺序一致;
  • 该表不指定自增列做主键,同时也没有可以被选为主键的唯一索引(上面的条件),这时候InnoDB会选择内置的ROWID作为主键,写入顺序和ROWID增长顺序一致;
  • 除此以外,如果一个InnoDB表又没有显示主键,又有可以被选择为主键的唯一索引,但该唯一索引可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况),该表的存取效率就会比较差。

实际情况是如何呢?经过简单TPCC基准测试,修改为使用自增列作为主键与原始表结构分别进行TPCC测试,前者的TpmC结果比后者高9%倍,足见使用自增列做InnoDB表主键的明显好处,其他更多不同场景下使用自增列的性能提升可以自行对比测试下。

附图:

1、B+树典型结构

B+tree

2、InnoDB主键逻辑结构

Innodb-primary-key

 

延伸阅读:

1、TPCC-MySQL使用手册

2、B+Tree index structures in InnoDB

3、B+Tree Indexes and InnoDB – Percona

4、MySQL官方手册: Clustered and Secondary Indexes

个人PPT分享

个人最近几年内整理过的PPT,都放在百度文库上了,大家可以看看 :)

M​y​S​Q​L​ ​t​p​c​h​测​试​工​具​简​要​手​册

高​效​L​i​n​u​x​ ​S​A​

P​C​服​务​器​阵​列​卡​管​理​简​易​手​册​

服​务​器​基​准​测​试

M​y​S​Q​L​数​据​库​设​计​、​优​化 

M​y​S​Q​L​之​设​计​、​优​化​、​运​维

 

迁移Zabbix数据库到TokuDB

背景介绍

线上的Zabbix数据库有几个大表数据量疯狂增长,单表已经超过500G,而且在早期也没做成分区表,后期维护非常麻烦。比如,想删除过期的历史数据,在原先的模式下,history、history_uint等几个大表是用 (itemid, clock) 两个字段做的联合主键,只用 clock 字段检索效率非常差。

TokuDB 是一个高性能、支持事务处理的 MySQL 和 MariaDB 的存储引擎。TokuDB 的主要特点是高压缩比,高 INSERT 性能,支持大多数在线修改索引、添加字段,特别适合像 Zabbix 这种高 INSERT,少 UPDATE 的应用场景。

迁移准备

欲使用 TokuDB 引擎,服务层可以选择和 MariaDB ,也可以选择 Percona ,鉴于我以往使用 Percona 的较多,因此本次也选择使用 Percona 版本集成 TokuDB 引擎。

当前最新版下载地址:http://www.percona.com/redir/downloads/Percona-Server-5.6/LATEST/binary/tarball/Percona-Server-5.6.17-rel66.0-608.TokuDB.Linux.x86_64.tar.gz

按照正常方式安装即可,配置文件中增加3行:

malloc-lib= /usr/local/mysql/lib/mysql/libjemalloc.so
plugin-dir = /usr/local/mysql/lib/mysql/plugin/
plugin-load=ha_tokudb.so

如果不加载jemalloc,启动时就会有类似下面的报错:

[ERROR] TokuDB not initialized because jemalloc is not loaded
[ERROR] Plugin 'TokuDB' init function returned error.
[ERROR] Plugin 'TokuDB' registration as a STORAGE ENGINE failed.

并且,修改内核配置,禁用transparent_hugepage,不关闭的话可能会导致TokuDB内存泄露(建议写到 /etc/rc.local 中,重启后仍可生效):

echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

如果不修改内核设置,启动时就会有类似下面的报错:

Transparent huge pages are enabled, according to /sys/kernel/mm/redhat_transparent_hugepage/enabled
Transparent huge pages are enabled, according to /sys/kernel/mm/transparent_hugepage/enabled
[ERROR] TokuDB will not run with transparent huge pages enabled.
[ERROR] Please disable them to continue.
[ERROR] (echo never > /sys/kernel/mm/transparent_hugepage/enabled)
[ERROR]
[ERROR] ************************************************************
[ERROR] Plugin 'TokuDB' init function returned error.
[ERROR] Plugin 'TokuDB' registration as a STORAGE ENGINE failed.

然后,初始化数据库,启动即可。

我的服务器配置:E5-2620 * 2,64G内存,1T可用磁盘空间(建议datadir所在分区设置为xfs文件系统),下面是我使用的相关选项,仅供参考:

#
#my.cnf
# 
# Percona-5.6.17, TokuDB-7.1.6,用于Zabbix数据库参考配置
# 我的服务器配置:E5-2620 * 2,64G内存,1T可用磁盘空间(建议datadir所在分区设置为xfs文件系统)
# TokuDB版本:Percona-5.6.17, TokuDB-7.1.6(插件加载模式)
# 
# created by yejr(http://imysql.com), 2014/06/24
# 
[client]
port            = 3306
socket          = mysql.sock
#default-character-set=utf8
 
[mysql]
prompt="\\u@\\h \\D \\R:\\m:\\s [\\d]>
#pager="less -i -n -S"
tee=/home/mysql/query.log
no-auto-rehash
 
[mysqld]
open_files_limit = 8192
max_connect_errors = 100000
 
#buffer & cache
table_open_cache = 2048
table_definition_cache = 2048
max_heap_table_size = 96M
sort_buffer_size = 2M
join_buffer_size = 2M
tmp_table_size = 96M
key_buffer_size = 8M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
bulk_insert_buffer_size = 32M
 
#innodb
#只有部分小表保留InnoDB引擎,因此InnoDB Buffer Pool设置为1G基本上够了
innodb_buffer_pool_size = 1G
innodb_buffer_pool_instances = 1
innodb_data_file_path = ibdata1:1G:autoextend
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 64M
innodb_log_file_size = 256M
innodb_log_files_in_group = 2
innodb_file_per_table = 1
innodb_status_file = 1
transaction_isolation = READ-COMMITTED
innodb_flush_method = O_DIRECT

#tokudb
malloc-lib= /usr/local/mysql/lib/mysql/libjemalloc.so
plugin-dir = /usr/local/mysql/lib/mysql/plugin/
plugin-load=ha_tokudb.so
 
#把TokuDB datadir以及logdir和MySQL的datadir分开,美观点,也可以不分开,注释掉本行以及下面2行即可
tokudb-data-dir = /data/mysql/zabbix_3306/tokudbData
tokudb-log-dir = /data/mysql/zabbix_3306/tokudbLog
 
#TokuDB的行模式,建议用 FAST 就足够了,如果磁盘空间很紧张,建议用 SMALL
#tokudb_row_format = tokudb_small
tokudb_row_format = tokudb_fast
tokudb_cache_size = 44G
 
#其他大部分配置其实可以不用修改的,只需要几个关键配置即可
tokudb_commit_sync = 0
tokudb_directio = 1
tokudb_read_block_size = 128K
tokudb_read_buf_size = 128K

迁移过程

建议在一台全新的服务器上启动Percona(TokuDB)实例进程,初始化新的Zabbix数据库,直接将大表转成TokuDB引擎,并且开启分区模式。这样相比直接在线ALTER TABLE或者INSERT…SELECT导入数据都要来的快一些(我简单测试了下,差不多能快2-3倍,甚至更高)。

在做数据迁移时,建议在目标服务器上做库表结构初始化,在源服务器上采用分段方式导出,一个表导出多个备份文件,方便在恢复时可以并发导入。在导入时,并且记得临时关闭 binlog,最起码设置 sync_binlog = 0 以及 tokudb_commit_sync = 0,以提高导入速度。采用 mysqldump 增加 -w 参数即可实现根据条件分段导出,具体可参考上一次的文章:[MySQL FAQ]系列— mysqldump加-w参数备份,或者是用MySQLDumper

需要用到外键的表继续保留InnoDB引擎,其他表都可以转成TokuDB,history_str、trends、trends_uint、history、history_uint等几个大表是一定要转成TokuDB的,events由于需要用到外键,所以继续保留InnoDB引擎。

我将表结构初始化SQL脚本提供下载了,一份是没有采用分区表的,一份是采用分区表的,大家可自行选择。一般如果记录数超过1亿,就建议使用分区表,根据时间字段(clock)分区,方便后期维护,例如删除过期历史数据什么的。

收尾

剩下的基本没啥可做的了,就是观察下运行状态,是否还有个别慢查询堵塞。在我的环境中,一开始把items表也转成TokuDB了,结果有个画图的SQL执行计划不准确,非常慢。后来发现items表也需要用到外键,于是又转回InnoDB表,这个SQL也恢复正常了。

数据库初始化脚本我整理后提供下载了,大家可以直接使用。

附件1:不使用分区表附件2:使用分区表

适用版本:

Zabbix版本:Zabbix 2.2.0
TokuDB版本:Percona-5.6.17, TokuDB-7.1.6(插件加载模式)

如果还有什么问题,欢迎加入我的QQ群(272675472)讨论。

MySQL 5.6.17/Percona5.6.16/MariaDB 10.0.11/OneSQL 5.6.16压测瓶颈分析

之前我进行了MySQL 5.6.17/Percona5.6.16/MariaDB 10.0.11/OneSQL 5.6.16对比基准TPCC压测,从测试结果可以看到在高并发(并发1920线程)模式下,MariaDB的相对优势,也看到了在一般并发场景(并发64线程)模式下,MariaDB拥有绝对优势。

今天我们就来看看这两种模式下,系统负载等性能指标表现,以及各自的瓶颈在哪里,也就能知道为何有这么大差异了。

首先,我们看下并发64线程的对比图表:

MySQL-Percona-MariaDB-perf-data-under-64th

再看下并发1920线程的对比图表:

MySQL-Percona-MariaDB-perf-data-under-1920th

从上面两个图可以看出来几点信息:

结论:
1、并发64线程时,MySQL的瓶颈在 spin_lock,所以 %SYS 跑的很高,TpmC也上不去;
2、并发64线程时,Percona次要瓶颈也是 spin_lock,相比之下 %SYS 也较高,TpmC上不去;
3、并发1920线程时,spin_lock 都是最大的瓶颈,MySQL和Percona的次要瓶颈是lock_rec_has_to_wait_in_queue()函数,因此相对的TpmC也跑不高;

MySQL 5.6.17/Percona5.6.16/MariaDB 10.0.11/OneSQL 5.6.16 TpmC测试

近日花了点时间对几个分支版本进行对比测试,包括了:MySQL 5.6.17、Percona5.6.16、MariaDB 10.0.11、OneSQL 5.6.16。

1、测试基准
测试工具: tpcc-mysql
测试Warehouse数: 10/100
warmup time: 120s
run time: 1800s
并发线程数: 64 ~ 1920
2、测试环境:
OS:RHEL 6.4
内核:2.6.32-358.el6.x86_64
磁盘:INTEL SSDSC2BA800G3
3、MySQL配置:
innodb_buffer_pool_size = 26G
sync_binlog = 0
innodb_flush_log_at_trx_commit = 1/3 #OneSQL设置为3,其他设置为1
tcc_max_transaction_concurrency = 64 #OneSQL设置

tpcc-mysql测试脚本可以参见我以前的一个分享:分享:服务器基准测试 或者 MySQL压力测试经验(放在slideshare上,需要翻)

下面是测试结果:

MySQL 5.6.17/Percona5.6.16/MariaDB 10.0.11/OneSQL 5.6.16 TpmC测试

MySQL 5.6.17/Percona5.6.16/MariaDB 10.0.11/OneSQL 5.6.16 TpmC测试

针对上面测试结果的说明:

结论:
1、在256并发以内的情况下,看起来MariaDB拥有绝对优势,应该和它的thread pool有很大关系;
2、OneSQL在100DW模式下,并发1792的拐点应该是个意外(其他测试循环中未出现该拐点),原因不明,可以忽略;
3、tpcc测试模式下,数据量越小、并发越高,则TpmC越低,因为竞争太厉害了,这方面OneSQL表现绝对优异,并发量变化很大对TpmC的影响很小;
建议:
1、是时候改成MariaDB了,因为它集成了XtraDB,已经超越Percona了;
2、如果没有特别的理由,可以不用官方版本了;
3、如果对楼方鑫的分支感兴趣并且可以放心上线的话,强烈推荐使用;

Nginx HttpMemcModule和直接访问memcached效率对比测试

  • 测试环境:
  1. 测试客户机A: HP DL380G4,2个双核CPU,4G Ram,2块10k RPM SAS盘做raid 1,ext3
  2. Nginx所在服务器B:DELL R710,E5620 * 2,32G Ram,6块盘15K RPM SAS盘做raid 1+0,xfs
  3. Memcached所在服务器C:DELL R710,E5620 * 2,32G Ram,6块盘15K RPM SAS盘做raid 5,ext4
  4. Nginx设置:keepalive 8192
  5. Php fpm设置:listen.backlog = -1
  6. memcached启动参数:memcached -d -m 24576 -p 12000 -c 10240
  7. 内核参数:
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_timestamps = 1

关于这几个内核参数对应的解释可参考资料:2.12. Reduce TCP performance spikes

  • 测试方案:
  1. 使用php连接本地nginx代理,存取远程memcached数据;
  2. 使用php直接连接远程memcached服务器;
  3. 从测试客户端用ab发起并发测试;
  4. 并发线程从64开始,直到2048,分别是64的N倍;
  5. 每种并发模式都进行5轮测试,最后取平均值;
  6. 存储在memcached中的key长度96个字符,value长度400字符,总是随机生成;
  • 测试结果:

NginxHttpMemcMC-vs-NativeMC-benchmark-2013091301  NginxHttpMemcMC-vs-NativeMC-benchmark-2013091302

NginxHttpMemcMC-vs-NativeMC-benchmark-2013091303  NginxHttpMemcMC-vs-NativeMC-benchmark-2013091304

结论及建议:

  1. Php程序通过HttpMemcMC访问memcache和直接访问memcached的效率并没有太多损失;
  2. 采用php直接访问memcached,失败的次数相比通过HttpMemcMC有较大增加,应该是HttpMemcMC在keepalive方面更有优势;
  3. 后续会在进行一次测试,调整nginx、php及内核相关参数,再做对比;
  4. 本次测试没有和正常的http请求混在一起对比,测试结果不具备绝对参考价值;

单从本次测试结果来看,HttpMemcMC值得拥有 :)

  • 结果结果更新:

调整上述几个内核参数:

net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1

通过调整内核参数,调整tcp连接复用性提高tcp效率,新的测试结果如下:

NginxHttpMemcMC-vs-NativeMC-benchmark-2013091305   NginxHttpMemcMC-vs-NativeMC-benchmark-2013091306 NginxHttpMemcMC-vs-NativeMC-benchmark-2013091307   NginxHttpMemcMC-vs-NativeMC-benchmark-2013091308

备注:由于2次测试案例中,每并发线程请求数不一样,所以你会发现两边的数据无法直接对比,这是我的失误,抱歉。

  • 补充小结:

调整完内核后:
1. 可以发现,HttpMemc的平均效率只有NativeMC 72.62%;
2. 调整内核tcp参数对提升tcp效率非常有帮助,Failed requests次数完全为0;
3. 由于可以提高memcached连接复用率以及对程序透明的好处,即便HttpMemc性能不如NativeMC,损失并不是非常厉害,仍然是可以接受的;

InnoDB memcached插件vs原生memcached对比性能测试

MySQL 5.6开始支持InnoDB memcached插件,也就是可以通过SQL高效读写memcached里的缓存内容,也支持用原生的memcache协议读写,并且可以实现缓存数据持久化,以及crash recovery、mysql replication、触发器、存储过程等众多特性,详细介绍可以查看:Benefits of the InnoDB / memcached Combination。看起来非常诱人,那就测试下看看吧,是驴子是马拉出来溜溜便知。

  • 环境准备
测试机 DELL PE R710
CPU E5620  @ 2.40GHz(4 core, 8 threads, L3 Cache 12 MB) * 2
内存 48G(8G * 6)
RAID卡 PERC H700 Integrated, 512MB, BBU, 12.10.1-0001
系统 Red Hat Enterprise Linux Server release 6.4 (Santiago)
内核 2.6.32-358.el6.x86_64 #1 SMP
raid级别 raid 5(10K RPM SAS 300G * 6)
文件系统 xfs
硬盘 10K RPM SAS 300G * 6, 1 hotspare
  • 测试方案
方案一 server端运行InnoDB MC,本地/远程调用memslap执行benchmark
方案二 server端运行Native MC,本地/远程调用memslap执行benchmark
  • 测试脚本
cat memslap_run.sh
#!/bin/sh

. ~/.bash_profile > /dev/null 2>&1

cd /home/mc-bench

exec 3>&1 4>&2 1>> memcache_memslap_${RANDOM}.log 2>&1

#不断循环
while [ 1 ]
do
#并发线程数 4 ~ 256
for THREAD in 4 8 16 32 64 128 256
do

#每种并发测试5次
count=1
max=5
while [ $count -le ${max} ]
do
#取样
echo "memstat"
memstat

# --flush 每次测试完毕钱,都先清空数据
# --binary 采用binary模式
# 初始化数据: 5000000, 每个并发线程存取数据量: 100000
# 并发256线程时, 总数据量可达 30,600,000
# 未指定 --test 选项,默认是进行 set 测试
memslap --server=mc_server:11211 --concurrency=${THREAD} --execute-number=100000 --initial-load=5000000 --flush --binary

count=`expr ${count} + 1`

#每次测试完毕后,都休息2分钟,等待服务器恢复空负载
if [ ${count} -lt ${max} ] ; then
 sleep 120
fi
echo ""
echo ""
done
done
done
  • 测试结果

1. 写MC

               线程数
耗时
256 128 64 32 16 8 4
NativeMC(单位:1秒) 104.315 47.646 24.486 12.162 6.351 5.525 5.078
InnoDBMC(单位:100秒) 339.1431 68.11128 27.67265 11.26917 4.968556 2.24988 1.104334

直接以曲线图方式对比:

 

nativemc-vs-innodbmc-benchmark-02-set-result-20130828

nativemc-vs-innodbmc-benchmark-02-set-result-20130828

2. 读MC

        线程数
耗时
4线程并发,2千万记录
本地Native MC 198.5016
本地InnoDB MC 327.239
远程Native MC 846.286
远程InnoDB MC 912.467

曲线图方式对比:

nativemc-vs-innodbmc-benchmark-03-get-result-20130828

nativemc-vs-innodbmc-benchmark-03-get-result-20130828

  • 结论

InnoDB MC看起来很美好,现实很骨感,其并发4线程写数据需呀的耗时,和原生memcached的256线程相当,差的不是一丁半点啊,还有很大优化空间。

而如果是缓存只读,InnoDB MC本地读取的效率大概是原生memcached的2/3,如果是远程读取,则相当于是本地读取效率的1/4 ~ 1/3。

  • 建议应用场景

鉴于上面的测试结果,建议将InnoDB MC这么来用:

1. 数据写入通过触发器(trigger)或者调度器(event scheduler)将待缓存数据同步到InnoDB MC缓存表中;

2. 以memcache API方式,通过本地/远程读取InnoDB MC中的缓存记录;

3. 尽可能减少通过远程方式往InnoDB MC写缓存数据;