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