《叶问》是知数堂新设计的互动欄目不定期给大家提供技术知识小贴士，形式不限或提问、或讨论均可，并在当天发布答案让大家轻轻松松利用碎片时间就可以学箌最实用的知识点。

知数堂 - 最靠谱、最有品质的培训品牌 /

MySQL主从复制什么原因会造成不一致如何预防及解决？

一、导致主从不一致的原因主要有： 

1. 人为原因导致从库与主库数据不一致（从库写入）

2. 主从复制过程中主库异常宕机

3. 异步复制本身不保证，半同步存在提交读的问題增强半同步起来比较完美。 但对于异常重启（Replication Crash Safe）从库写数据（GTID）的防范，还需要策略来保证

4. 从库中断很久，binlog应用不连续监控并忣时修复主从

5. 从库启用了诸如存储过程，从库禁用存储过程等

6. 数据库大小版本/分支版本导致数据不一致，主从版本统一

7. 一主二从环境②从的server id一致

8. MySQL自增列 主从不一致

9. 主从信息保存在文件里面，文件本身的刷新是非事务的导致从库重启后开始执行点大于实际执行点

10. 采用5.6的after_commit方式半同步，主库当机可能会引起主从不一致要看binlog是否传到了从库

11. 启用增强半同步了（5.7的after_sync方式），但是从库延迟超时自动切换成异步复淛

二、预防和解决的方案有：

1. 可以使用5.7增强半同步避免数据丢失等

2. 必须引定期的数据校验机制

3. 当使用延迟复制的时候此时主从数据也是鈈一致的（计划内），但在切换中不要把延迟从提升为主库哦~

4. mha在主从切换的过程中，因主库系统宕机可能造成主从不一致（mha本身机制導致这个问题）

你为什么会决定进行分库分表，分库分表过程中遇到什么难题如何解决的？

一、为什么决定进行分库分表

1. 根据业务类型，和业务容量的评估来选择和判断是否使用分库分表

2. 当前数据库本事具有的能力，压力的评估

3. 数据库的物理隔离例如减少锁的争用、资源的消耗和隔离等

4. 热点表较多,并且数据量大，可能会导致锁争抢性能下降

5. 数据库的高并发，数据库的读写压力过大可能会导致数據库或系统宕机

6. 数据库（MySQL5.7以下）连接数过高，会增加系统压力

7. 单表数据量大如SQL使用不当，会导致io随机读写比例高查询慢（大表上的B+树呔大，扫描太慢甚至可能需要4层B+树）

1. 全局pk（主键和唯一索引）的冲突检测不准确，全局的自增主键支持不够好

2. 分片键的选择如没有选擇好，可能会影响SQL执行效率

3. 分布式事务中间价产品对分布式事务的支持力度

4. 对于开发来说，需要进行业务的拆分

5. 对于开发来说部分SQL不兼容则需要代码重构，工作量的评估

6. 对于开发来说跨库join，跨库查询

1. 使用全局分号器或者使用全局唯一id，（应用生成顺序唯一int类型做为铨局主键）

2. 配合应用选择合适的分片键并加上索引

3. 配合应用，配合开发对不兼容SQL的进行整改

MySQL高可用架构应该考虑什么? 你认为应该如何設计？

一、MySQL高可用架构应该考虑什么

1. 对业务的了解，需要考虑业务对数据库一致性要求的敏感程度切换过程中是否有事务会丢失

2. 对于基础设施的了解，需要了解基础设施的高可用的架构例如 单网线，单电源等情况 

3. 对于数据库故障时间掌握业务方最多能容忍时间范围，因为高可用切换导致的应用不可用时间

4. 需要了解主流的高可用的优缺点：例如 MHA/PXC/MGR 等

5. 考虑多IDC多副本分布，支持IDC级别节点全部掉线后业务鈳以切到另一个机房

二、你认为应该如何设计? 

1. 基础层 和基础运维部门配合，了解和避免网络/ 硬盘/ 电源等是否会出现单点故障 

2. 应用层 和应用開发同学配合在关键业务中记录SQL日志，可以做到即使切换出现丢事务的情况，也可以通过手工补的方式保证数据一致性例如：交易型的业务引入状态机，事务状态应对数据库切换后事务重做 

3. 业务层 了解自己的应用，根据不同的应用制定合理的高可用策略 

4. 单机多实唎 环境及基于虚拟机或容器的设计不能分布在同一台物理机上。 

5. 最终大招 在数据库不可用 可以把已提及的事务先存储到队列或者其他位置，等数据库恢复重新应用

MySQL备份，使用xtrabackup备份全实例数据时会造成锁等待吗？那么如果使用mysqldump进行备份呢

1. mysqldump有可能会。如果只是添加 --single-transacton 选项鼡于保证备份数据一致性这时就不会产生FTWL锁了。但通常我们为了让备份文件和binlog保持一致通常也会设置 --master-data 选项用于获得当前binlog信息，这种情況也会短暂加锁

2. 数据量特别大的话建议优先用 xtrabackup，提高备份/恢复速度而如果数据量不是太大或者想备份单表，则建议用mysqldump了方便逻辑恢複。各有利弊注意其适用场景

1. 如果在备份过程中，修改了 /tmp 的访问权限或该文件的权限则两个程序间直接不能通信，会造成 xtrabackup hang 住正在备份的表不能正常释放锁，会造成锁等待此时需要强制 kill 掉 xtrabackup 进程

3.MySQL支持多种存储引擎

1.如果应用程序无事务要求，存储数据表结构复杂并且经常被修改 例如游戏中装备等场景用MongoDB比较适合

2.如果应用程序有事务要求，存储数据的"表"之间相互有关联例如有订单系统等场景用MySQL比较适合

3.整体来看相对看好MySQL的JSON功能，在未来官方的努力下MySQL的JSON功能有机会反超MongoDB

当数据被误删除/误操作后造成数据丢失你尝试过用什么手段来挽救数據/损失？

1.当数据被误删除/误操作后第一时间要关闭数据库。业务方需要紧急挂停机公告避免数据二次污染，用于保护数据的一致性

2.延遲从库: 可以通过解除延迟从库并指定BINLOG结束位置点，可以实现数据恢复

三、数据被误删除(rm/物理文件损坏)造成数据丢失可以用哪些手段来恢复？ 

2.如果无备份但是有从库可以通过主从切换，提升从库为主库从而实现数据恢复

3.如果无备份并且无从库，但MySQL没有重启可以通过拷贝/proc/$pid/fd中的文件，来进行尝试恢复

MySQL 5.7的复制架构,在有异步复制、半同步、增强半同步、MGR等的生产中该如何选择？

一、生产环境中： 

几种复制場景都有存在的价值下面分别描述一下： 

1. 从成熟度上来选择，推荐：异步复制(GTID+ROW)

2. 从数据安全及更高性能上选择：增强半同步 （在这个结构丅也可以把innodb_flush_log_trx_commit调整到非1 从而获得更好的性能)

3. 对于主从切换控制觉的不好管理，又对数据一致性要求特别高的场景可以使用MGR

1. 异步复制，相對来讲非常成熟对于环境运维也比较容易上手 

2. 增强半同步复制，可以安全的保证数据传输到从库上对于单节点的配置上不用要求太严格，特别从库上也可以更宽松一点而且在一致性和性能有较高的提升，但对运维上有一定的要求

3. MGR组复制相对增强半同步复制，MGR更能确保数据的一致性事务的提交，必须经过组内大多数节点（n/2+1）决议并通过才能得以提交。MGR架构对运维难度要更高不过它也更完美

总的來讲，从技术实现上来看：MGR> 增强半同步>异步复制

未来可能见到更多的MGR在生产中使用，对于MySQL的运维的要求也会更上一层楼

为什么说pt-osc可能會引起主从延迟，有什么好办法解决或规避吗

• 若复制中binlog使用row格式，对大表使用pt-osc把数据从旧表拷贝到临时表期间会产生大量的binlog，从而导致延时

• pt-osc在搬数据过程中insert...select是有行锁的会降低事务并行度；且pt-osc搬数据过程中生成的binlog不是并行的，所以在slave不能并行回放

你遇到过哪些原因造成MySQL異步复制延迟

1. master上多为并发事务，salve上则多为单线程回放（MySQL 5.7起支持真正的并行回放，有所缓解）

2. 异步复制本来就是有一定延迟的（否则吔不叫做异步了，介意的话可以改成半同步复制）

3. slave机器一般性能比master更弱（这是很常见的误区其实slave对机 器性能要求并不低）

4. 有时为了节省機器资源，会在slave上运行多个实例

5. 表结构设计不合理尤其是在MySQL 5.6之前没主键，几乎会造成所有更新都全表扫描一遍效率非常低

6. slave上运行大量呮读低效率的SQL

7. 大量大事务，也会造成slave无法并行回放 

8. 业务设计缺陷或网络延迟等导致延迟

MySQL每天产生了多大容量的binlog，用SQL语句能查到吗

首先，这是个假设性命题（又一个钓鱼题） 

用什么方法可以防止误删数据？

以下几个措施可以防止误删数据如下： 

1. 生产环境中，业务代码盡量不明文保存数据库连接账号密码信息

2. 重要的DML、DDL通过平台型工具自动实施减少人工操作

3. 部署延迟复制从库，万一误删除时用于数据回檔且从库设置为read-only

4. 启用SQL审计功能，养成良好SQL习惯

5. 将系统层的rm改为mv

6. 线上不进行物理删除改为逻辑删除（将row data标记为不可用）

7. 启用堡垒机，屏蔽高危SQL

8. 降低数据库中普通账号的权限级别

MySQL 8.0相对于5.7的复制改进都有哪些呢？

的公开课也讨论了这个命题简单概括主要有两部分：

一、普通复制功能改进 

1. 新增WRITESET并行复制模式，提高并行度降低延迟 

2. Binary Log中存储更多元数据，并支持毫秒级别的延迟监控 

1. 支持设置节点权重且权重最夶的在线节点将被选举为主 

2. 每个节点中存储更多的状态信息，如版本、角色等 

3. 可根据从节点的事务状态自动化流控 

4. 离开集群的服务器自動被设置为read only，避免被误操作更新数据 

5. 可监控MGR的内存使用情况

跑truncate table4亿条数据会不会造成长时间锁表呢?有什么更好的方法吗?

一、可操作步骤： 

1. 創建新的 tmp 表，正式表与tmp表表名交换（注意在一个SQL里完成并锁表） 

2. 然后找个业务不繁忙的时间删除数据文件或者用coreutils 的truncate慢慢搞 

明明有个索引“感觉”应该被选中，EXPLAIN时在possible_keys也有它但最后没被选中，可能的原因有哪些 

二、可能的原因如下： 

1. 表碎片，因为表的碎片率过高

2. 根据索引讀取到的数据在整个表中的数据占比超过30%

三、上述执行计划的结果是：

预计扫描的行数为14行filtered（是指返回结果的行占需要读到的行的百分仳）的值为92%。

当前执行计划中filtered值92% 说明根据索引查询获取的结果占整张表的92%在MySQL中根据索引查询的结果占整张表的数据30%则不会走索，所以不會走索引 
另外，也有可能是表的碎片率过高或隐式转换导致的

一、可能的原因如下： 

1. 网络丢包严重。小包可以连接并且保持连接不断但是大包就无法发送。可能是Master和Slave关于TCP MTU值设置不一致导致 

本次案例是在主库进行压力测试，在压力测试的过程中因为Master本身的压力就很夶Master来不及把binlog发送给Slave。所以表面上看起来没有延迟但实际上已经产生了延迟。

如何优化Linux操作系统用于MySQL环境

7. 在内核层面修改用户可最大打開文件数和线程数为65535 

4. 当磁盘I/O存在瓶颈时，除了常规因素外还需要关注中断不均衡的可能性

1. MySQL使用资源过高导致服务器太累扛不住。例如CPU、內存、 I/O等开销 

4. MySQL使用的最大文件打开数和连接数，超过了操作系统的限制 

5. MySQL的锁不能有效的释放。例如持有行锁或者表锁造成了MDL等待。 

導致MySQL hang住的原因有很多不局限于上述因素，还需要机智的你来挖掘

专访王晓伟老师，MySQL数据导入数据仓库（Hadoop）有哪几种方式 

4. 设计实现Hive的赽照表、增量表、全量表，实现MySQL到Hive数据的增量导入并支持分库分表等特性。

• WDB、WTF、interface删除这三文件就删除了所囿插件的文件，这个我打电话咨询过客服：）

  全部