1、在有主键或者唯一键的情况下，Slave 重放 Binlog 并不会去比较检索到的记录的每一列是否和BI相同，因此如果 Slave 和 Master 存在数据不一致，会直接覆盖 Slave 的数据而不会报错。
房山ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18980820575（备注：SSL证书合作）期待与您的合作！
2、在索引列上进行了函数操作，MySQL内部会进行了隐式转换，导致索引失效，从而产生全表扫描。由于笔者知识及水平有限，文中错漏之处在所难免，如有不足之处，欢迎交流。
3、避免全表扫描通常情况下，如果MySQL（或者其他关系数据库模型）需要在数据表中搜索或扫描任意特定记录时，就会用到全表扫描。此外，通常最简单的方法是使用索引表，以解决全表扫描引起的低效能问题。
引出的问题：如果数据库出现故障，我们的业务就不能使用，只能说是停机重启修复故障。由于单体带出的问题，这时候我们就需要加一个备用库，紧急情况可以用备库顶上，相当于加一个替补队员。
数据延迟的处理是减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。数据延迟是指存储或检索数据包的时间。
数据库修改后是可以立即生效和同步的，如果数据涉及前台显示，可能需要在网站后台进行一次刷新才会立即生效。加速服务器可以使用CDN网络加速，网上有一些免费的也有收费的，具体根据实际情况选择。
关于同步，延迟的方法比较单一，做一个存储，加在作业里，定时调用即可。即时的可以分两种思路，第一可以用触发器的方式，在db1中需要同步的表里，创建触发器，当有数据操作的时候触发，同步数据。
所以每执行一次都要做全表扫描才能定位到要删除的那一条数据，可想而知同步效率会低很多。解决方案：1 表设计时就要有主键；2 如果延迟已经发生，并且表不是特别大的情况下，在备库上为该表创建索引或是主键。
而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。
比如楼哥之前面试小米，就被问到过主从复制的原理，以及主从延迟的解决方案，因为回答的非常不错，给面试guan 留下非常好的印象。
主从复制的设计问题 优化：主从复制单线程，可以通过多线程IO方案解决；另外MySQL3支持多线程IO复制。主从库之间的网络延迟 优化：尽量链路短，提升端口带宽 主库读写压力大 优化：前端加buffer和缓存。
mysql-3已经支持了多线程的主从复制。原理和丁奇的类似，丁奇的是以表做多线程，Oracle使用的是以数据库(schema)为单位做多线程，不同的库可以使用不同的复制线程。
该工具可以计算出MySQL复制或者是PostgreSQL，它可以更新master或者监控复制。它还可以从my点吸烟 f 读取配置。它借助timestmp的比较实现的，首先需要保证主从服务器时间必须要保持一致，通过与相同的一个NTP server同步时钟。
首先要在本地建立两个mysql服务(参考这里)，指定不同的端口。我这里一个主(3306)，一个从(3307)。
引出的问题：如果数据库出现故障，我们的业务就不能使用，只能说是停机重启修复故障。由于单体带出的问题，这时候我们就需要加一个备用库，紧急情况可以用备库顶上，相当于加一个替补队员。
表设计时就要有主键；2 如果延迟已经发生，并且表不是特别大的情况下，在备库上为该表创建索引或是主键。
对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点。
最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。
解决该问题的方法，除了缩短主从延迟的时间，还有一些其它的方法，基本原理都是尽量不查询从库。
由于问题产生的来源是主从延迟，所以在下一次查询的时候进行一段时间的等待以弥补这种延迟即可。所以在进行主库的数据插入之后，让数据库数据连接或者对应的执行线程等待一段时间后返回。通过等待时间来消化掉主从备份的延迟时间。
