replace的工作机制有点像insert,只不过如果在表里如果一行有PRIMARY KEY或者UNIQUE索引，那么就会把老行删除然后插入新行。如：
binlog格式：
binlog格式：
binlog格式：
疑问：
既然uk冲突的时候是update，那么为什么affect_rows都是2呢？
用的时候需要注意的是：
- 如果指定replace列的话，尽量写全，要不然没有输入值的列数据会被赋成默认值（因为是先delete在insert），就和普通的insert是一样的，所以如果你要执行replace语句的话是需要insert和delete权限的。
如果你需要执行 ,就相当于执行. - replace语句如果不深入看的话，就和insert一样，执行完后没什么反应
例：
MySQL给replace和load data….replace用的算法是:
- 尝试向表里插入新行
- 当表里唯一索引或者primary key冲突的时候：
a. delete冲突行
b.往表里再次插入新行
如果遇到重复行冲突，存储过程很可能当作update执行，而不是delete+insert，但是显式上都是一样的。这里没有用户可见的影响除了存储引擎层Handler_的状态变量。
因为REPLACE … SELECT语句的结果依赖于select的行的顺序，但是顺序没办法保证都是一样的，有可能从master和slave的都不一样。正是基于这个原因，MySQL 5.6.4以后，REPLACE … SELECT语句被标记为基于statement的复制模式不安全的。基于这个变化，当使用STATEMENT记录二进制日志的时候，如果有这样的语句就会在log里面输出一个告警,同样当使用MIXED行复制模式也会记录告警。
在MySQL5.6.6之前的版本，replace影响分区表就像MyISAM使用表级锁锁住所有的分区表一样。当使用 语句时确实会发生上述情况。(使用基于行锁的InnoDB引起不会发生这种情况。)在MySQL 5.6.6以后的版本MySQL使用分区锁，只有当分区(只要没有分区表的列更新)包含了REPLACE语句并且WHERE实际匹配到的才会锁住那个分区;否则的话就会锁住整个表。
操作形式：
binlog格式：
- 当存在pk冲突的时候是先delete再insert
- 当存在uk冲突的时候是直接update
在主备复制的时候，row模式会对replace into语句产生increment主键的自增长，主从两边不一致问题。
主库上如上执行后，备库里如果是auto_increment是不会变的！这会有什么问题呢？把这个 slave 提升为 master 之后，由于 AUTO_INCREMENT 比实际的 next id 还要小，写入新记录时就会发生 duplicate key error，每次冲突之后 AUTO_INCREMENT += 1，直到增长为 max(id) + 1 之后才能恢复正常。
2. 数据迁移
莫名其妙发现有些字段的值被覆盖
鉴于此，很多使用 REPLACE INTO 的场景，实际上需要的是 INSERT INTO … ON DUPLICATE KEY UPDATE，在正确理解 REPLACE INTO 行为和副作用的前提下，谨慎使用 REPLACE INTO。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/141834.html