在大表执行ddl的过程中，若临时中断，会发生什么状况，需要特别处

目录

MySQL的表中有唯一索引，设置unique_checks为0时，还能否写入重复值？

在数据检索的条件中使用!=操作符时，存储引擎会放弃使用索引

Redis集群的slot迁移是如何实现的?

在大表执行ddl的过程中，若临时中断，会发生什么状况，需要特别处理吗 ？

---

一、MySQL的表中有唯一索引，设置unique_checks为0时，还能否写入重复值？

首先，即便设置unique_checks=0，也无法往唯一索引中写入重复值。

其次，设置unique_checks=0的作用在于，批量导入数据（例如load data）时，在确保导入数据中无重复值时，无需再次检查其唯一性，加快导入速度。

所以，unique_checks=0并不是允许唯一约束失效，而是再批量导数据时不再逐行检查唯一性。

二、某人曰，在数据检索的条件中使用!=操作符时，存储引擎会放弃使用索引。 理由：因为检索的范围不能确定,所以使用索引效率不高，会被引擎自动改为全表扫描。

你认可他的说法吗？

答：通常情况下，这个说法是正确的。当然，也有特殊情况，话不能说绝对了。

有一个测试表共80万条数据，其中type列只有1、2两个值，分别占比97%和3%。

这种情况下，查询条件 WHERE type != 1，是有可能也可以走索引的。

下面是两个SQL的执行计划：

************ 1. row ************

id: 1

select_type: SIMPLE

table: t1

partitions: NULL

type: ref

possible_keys: type

key: type

key_len: 4

ref: const

rows: 399731

filtered: 100.00

Extra: NULL

mysql> desc select * from t1 where type != 1\G

************ 1. row ************

id: 1

select_type: SIMPLE

table: t1

partitions: NULL

type: ref

possible_keys: type

key: type

key_len: 4

ref: const

rows: 10182

filtered: 100.00

Extra: NULL

type数据分布

mysql> select type, count(*) as cnt from t1 group by type order by cnt;

+------+--------+

| type | cnt |

+------+--------+

| 2 | 38304 |

| 1 | 761690 |

+------+--------+

三、Redis集群的slot迁移是如何实现的?

答：迁移源slot设置为migrating 状态，迁移目标slot设置为importing状态。

在内部用dump & restore命令，把数据迁移到目标节点，迁移结束之后，移除migrating和importing状态。

在迁移过程中如果有数据访问，如果数据没迁移到目标节点，那么直接返回结果，如果迁移到目标节点，那么给客户端返回ASK重定向。

四、在大表执行ddl的过程中，若临时中断，会发生什么状况，需要特别处理吗 ？

前提说明：MySQL5.7.23、innodb表、“双1”

1、添加/删除列，采用copy的方式

1.1  ctrl+c。在当前session中，手动执行ctrl+c。无影响，并且会自动删除产生的临时文件。

1.2  kill -9。在执行ddl的时候，服务器发生意外宕机或者手动执行kill -9。待MySQL启动后，则会自动执行InnoDB Recovered流程。并且不会删除产生的临时文件，需要手工处理。

2、添加/删除索引，采用INPLACE方式

2.1  ctrl+c，在当前session中，手动执行ctrl+c。无影响，并且会自动删除产生的临时文件。

2.2  kill -9。不会删除临时文件，也不会执行InnoDB Recovered流程并且报错 Operating system error number 2 in a file operation ....OS error: 71

在开始执行alter table的过程中，在没有结束的时候，并不会写入到binglog文件中。