用 pt-table-checksum 时,会不会影响业务性能?
实验
实验开始前,给大家分享一个小经验：任何性能评估,不要相信别人的评测结果,要在自己的环境上测试,并（大概）知晓原理.
我们先建一对主从：
然后用 mysqlslap跑一个持续的压力：
开另外一个会话,将 master 上的 general log 打开：
然后通过 pt-table-checksum 进行一次比较：
查看 master 的 general log,由于 mysqlslap 的影响,general log 中有很多内容,我们找到与 pt-table-checksum 相关的线程：
将该线程的操作单独列出来：
操作比较多,我们一点一点来说明：
这里工具调小了 innodb 锁等待时间.使得之后的操作,只要在 innodb 上稍微有锁等待,就会马上放弃操作,对业务影响很小.
另外工具调小了 wait_timeout 时间,倒是没有特别的作用.
工具将隔离级别调整为了 RR 级别,事务的维护代价会比 RC 要高,不过后面我们会看到工具使用的每个事务都很小,加上之前提到 innodb 锁等待时间调到很小,对线上业务产生的成本比较小.
RR 级别是数据对比的基本要求.
工具通过一系列操作,了解表的概况.工具是一个数据块一个数据块进行校验,这里获取了第一个数据块的下边界.
此时此刻呢工具获取了下一个数据块的下边界,每个 SQL前都会 EXPLAIN 一下,看一下执行成本,非常小心翼翼.
之后工具获取了一个数据块的 checksum,这个数据块不大,如果跟业务流量有冲突,会马上出发 innodb 的锁超时,立刻退让.
好了,全部的 pt-table-checksum 的一些设计,可以看到这几处都是精心维护了业务流量不受影响.
工具还设计了其他的一些机制保障业务流量,比如参数 --max-load 和 --pause-file 等,还有精心设计的数据块划分方法,索引选择方法等.大家根据自己的情况配合使用即可达到很好的效果.
总结
本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量,坊间会流传工具的各种参数建议或者不建议使用,算命的情况比较多,大家都可以用简单的实验来分析其中机制.
还是那个观点,性能测试不能相信道听途说,得通过实验去分析.
①.、优化设计的技巧
(1) 如果一个字段需要经常更改,则采用以空间换时间的设计方法
最常见的例子是用户积分登录次数的累加,按照范式设计,在users表中建立一个字段us_scores,以后需要在用户积分改变时采用update的语句进行修改.但是知道 update语句的执行速度是很慢的,为了避免大量重复使用它,优化的设计方案是建立us_scores表,存储每次增加的积分,在查询是采用SQL语句的sum方法来计算之.
索引的建立是加快数据库查询的基本技巧之一,通常的建议是,只有百万级的记录的表格才应该建立索引.
,命名都应该作为非常重要的事情来看待,表、序列、字段、索引的命名技巧可以归结如下：
(1) 关联字段名称必须相同,名称以基础表的字段名称为准
一,保证规范,序列名称必须是唯一的,而且,一般的序列就是这个表的id字段.如果不加前缀,那么字段都叫做id就会违背惟一性原则.
第二,为了将来关联查询语句的书写方便.
为了提高大数据量的表格的查询速度,可以采用建立适当的索引方式.如果一个表只有一个索引,建议索引的名字跟表相同,如果有多个索引,则为表名称加下划线加索引列名称.
最安全的设计方案是,Web数据库和测试数据库分离.Web数据库权限只被管理员一个人掌握.
关于MySQL数据库设计
的优化措施还需要经过数据库设计人员的不断发掘,从数据库设计中不断的发现问题,提出解决问题的方法,才能将数据库的性能优化的更好更全面.
mysqldump命令将数据库中的数据备份成一个文本文件.表的结构和表中的数据将存储在生成的文本文件中.
mysqldump命令的工作原理很简单.它先查出需要备份的表的结构,再在文本文件中生成一个CREATE语句.然后,将表中的所有记录转换成一条INSERT语句.然后通过这些语句,就能够创建表并插入数据.
以上就是土嘎嘎小编大虾米为大家整理的相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用，就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！