压测数据全记录

MySQL5.5原生版本，sync_binlog 1000 innodb_flush_log_at_trx_commit 2

1. 死锁检测

压测场景：

一个事务里面先insert,再update,insert随意，update对同一条记录更新,并发128,循环10000次

压测结果：

关闭死锁检测tps:5705 打开死锁检测tps:1659,

结论：

在对tps要求比较高的场景中关闭死锁检测很有必要,但是前提是整个涉及的场景中没有死锁，否则的话，关闭死锁检测只会起到相反的作用

2. 备库延迟

压测场景：

尽量让主库的tps高,看主库的tps达到多少时备库开始延迟

压测结果：

主库的tps达到9k以上时，备库开始延迟,主库的tps在9k-1w时，备库的延迟时间在1s之内;主库的tps在1w~1.2w的时候，备库的延迟在100s以内;多实例下也是一样的

 3. innodb表，根据id更新和根据uk更新性能上差异多大

压测背景：

id是主键,uk (iid,sid)

压测结果：

语句：

update a set q=q-0, v=v+1, gmt_modified=now(), rq = CASE WHEN ((rq + 2 ) >= 0 ) then rq + 2 
ELSE 0 END where id=200060000007408609 and iid=9749545200 and sid = 0 and (q - rq - 2) >= 0 and q-0>=0;

结果：

Summary: SQL01 exec=537849, rows=537849=100/e, avg=140840 us
Summary: exec=896/s, qtps=896/s

语句：

update a set q=q-0, v=v+1, gmt_modified=now(), rq = CASE WHEN ((rq + 2 ) >= 0 ) then rq + 2 

ELSE 0 END where iid=9749545200 and sid = 0 and (q - rq - 2) >= 0 and q-0>=0;
结果：
Summary: SQL01 exec=633689, rows=633689=100/e, avg=147471 us
Summary: exec=768/s, qtps=768/s

结论：

如果可以尽量使用id更新吧

4. 两套同样的写语句放到事务里和不放到事务里性能相差多大？

事务版本

1024个并发

insert a exec=23592, rows=23592=100/e, avg=420 us
update b exec=25600, rows=25600=100/e, avg=91622 us
Summary: exec=2599/s, qtps=5182/s

伪事务版本

insert a exec=23556, rows=23556=100/e, avg=652 us

update b exec=25600, rows=25600=100/e, avg=37346 us

Summary: exec=6624/s, qtps=12867/s

事务版本是伪事务版本的一半性能

低压力下出高性能

128个并发

事务版本

insert a exec=11745, rows=11745=100/e, avg=366 us
update b exec=12800, rows=12800=100/e, avg=41315 us--锁时间
Summary: exec=2968/s, qtps=5761/s

伪事务版本

insert a exec=11756, rows=11756=100/e, avg=518 us
update b exec=12800, rows=12800=100/e, avg=14483 us--update锁时间
Summary: exec=8488/s, qtps=16343/s

 

转载于:https://www.cnblogs.com/sunss/p/3163019.html