Leon📷 置顶2019-01-30kill connection本质上只是把客户端的sql连接断开，后面的执行流程还是要走kill query的，是这样理解吧作者回复: 这个理解非常到位👍
额外的一个不同就是show processlist的时候，kill connection会显示“killed”
这两句加起来可以用来替换我们文中的描述👍 17- 2019-01-25老师，我想问下这些原理的"渔"的方法除了看源码，还有别的建议吗
作者回复: 不同的知识点不太一样哈，
有些可以看文档；
有些可以自己验证；
还有就是看其他人文章，加验证；（就是我们这个专栏的方法^_^） 7 
2019-02-13老师，之前也是有遇到程序问题导致cpu爆满，临时先把innodb_thread_concurrency设置为16（降低cpu避免影响同机器实例），然后不断去kill，后面程序人员修复了这个问题后，一堆的killed的语句不释放，设置innodb_thread_concurrency=0，等了半个月都没释放，后面还是安排主从切换，强制重启解决，请问老师，这是为什么？作者回复: 如果是因为这个原因的，应该是设置innodb_thread_concurrency=0就会退出的。。
你这个情况可能卡在别的地方了，下次如果再出现，要重启之前，用pstack保留个现场哦 5
2019-01-26课后题。我认为需要看当时的业务场景。重启会导致其他的连接也断开，返回给其他业务连接丢失的错误。如果有很多事务在等待该事务的锁，则应该重启，让其他事务快速重试获取锁。另外如果是RR的事务隔离级别，长事务会因为数据可见性的问题，对于多版本的数据需要找到正确的版本，对读性能是不是也会有影响，这时候重启也更好。个人理解，请老师指正。作者回复: 有考虑到对其他线程的影响，这个👍
其实这种时候往往是要先考虑切换（当然重启也是切换的）
如果只看恢复时间的话，等待会更快 4- 2019-01-25对于结尾的问题,我觉得肯定是等待,即便是mysql重启,也是需要对未提交的事务进行回滚操作的,保证数据库的一致性 4
2019-12-26老师好，文中 set global innodb_thread_concurrency=2的那个例子，前面 Session A 和 Session B 已经占用了两个线程了，那为什么我们还可以在一个新的Session中执行 Kill 或 show full processlist 命令呢？作者回复: 执行kill的时候没进InnoDB，不受这个参数限制的
3
2019-02-19请教老师，删除中间列和修改末尾列这两种DDL的差别在什么地方呢？
作者回复: 对，其实只有 改索引、 加最后一列、删最后一列
其他的大多数不行，比如删除中间一列这种作者回复: 删除中间列，就没办法用切换的那个方案。
MySQL的备库比主库多一个字段或少一个字段，这时候日志还是可以应用成功的（但如果少的是中间一个字段，字段就会对应错了） 3
2019-03-13老师，请问我直接在操作系统层面用kill命令掉会话的进程，这个会话的事物应该会回滚，除此外有不良影响吗？作者回复: 就是回滚的影响，没有其他的了
1 1
2019-02-13老师如果正在执行ddl 比如删除一列或者创建一个索引，执行kill query也是事物进行回滚的是吗？内部会做什么操作？ 来得晚还没追上课程。谢谢解答！作者回复: 对，进行回滚
取决于做到什么程度了，总之效果就是中间生成的数据全部清理掉，恢复到未执行ddl之前的状态 1
2019-01-28“采用不缓存的方式时，如果本地处理得慢，就会导致服务端发送结果被阻塞，因此会让服务端变慢” 这个怎么理解？作者回复: 堵住了不就变慢了😆
1
2019-01-27老师，您好。客户端版本如下：
mysql Ver 14.14 Distrib 5.7.24, for linux-glibc2.12 (x86_64) using EditLine wrapper
老师，再请教另一个问题。并非所有的 DDL 操作都可以通过主从切换来实现吧？不适用的场景有哪些呢？作者回复: 对，其实只有 改索引、 加最后一列、删最后一列
其他的大多数不行，比如删除中间一列这种 1
2019-01-27可能不是本章讨论的问题，我想请问老师“MySQL使用自增ID和UUID作为主键的优劣”，基于什么样的业务场景用哪种好?作者回复: 后面会有文章会提到这个问题哈：）
1- 2019-01-26也遇到@发条橙子一样的问题，例如队列两个消息同时查询库存，发现都不存在，然后就都执行插入语句，一条成功，一条报唯一索引异常，这样程序日志会一直显示一个唯一索引报错，然后重试执行更新，我暂时是强制查主库
作者回复: “我暂时是强制查主库” 从这就看你是因为读是读的备库，才出现这个问题的是吧。
发条橙子的问题是，他都是操作主库。
其实如果索引有唯一键，就直接上insert。
然后碰到违反唯一键约束就报错，这个应该就是唯一键约束正常的用法吧😆 1 
2019-01-26老师您好，一个表中 1个主键，2个唯一索引，1个普通索引 4个普通字段，当插入一条全部字段不为空的数据时，此时假设有4个索引文件，分别对应 主键 唯一性索引，普通索引，假设内存中没有这个数据页，那么server是直接调用innodb的接口，然后依次校验 （读取磁盘数据，验证唯一性）主键，唯一性索引，然后确认无误A时刻之后，吧主键和唯一性索引的写入内存，再把普通索引写入change buffer？那普通数据呢，是不是跟着主键一块写入内存了？作者回复: 1. 是的，如果普通索引上的数据页这时候没有在内存中，就会使用change buffer
2. “那普通数据呢，是不是跟着主键一块写入内存了？” 你说的是无索引的字段是吧，这些数据就在主键索引上，其实改的就是主键索引。 1- 2019-01-25老师，请教。
1）文中开头说“当然如果这个线程有语句正在执行，也是要先停止正在执行的语句的”。我个人在平时使用中就是按默认的执行，不管这个线程有无正在执行语句。不知这样会有什么潜在问题？
2）文中说“实际上，执行 Ctrl+C 的时候，是 MySQL 客户端另外启动一个连接，然后发送一个 kill query 命令“。这个怎么解释呢？
我开启 general log 的时候执行 Ctrl+C 或 Ctrl+D 并没有看到有另外启动一个连接，也没有看到 kill query 命令。general log 中仅看到对应线程 id 和 Quit。
3）MySQL 为什么要同时存在 kill query 和 kill connection，既然 kill query 有无效的场景，干嘛不直接存在一个 kill connection 命令就好了？那它俩分别对应的适用场景是什么，什么时候考虑 kill query，什么时候考虑 kill connection？我个人觉得连接如果直接被 kill 掉大不了再重连一次好了。也没啥损失。
4）小小一个总结，不知对否？
kill query - 会出现无法 kill 掉的情况，只能再次执行 kill connection。
kill connection - 会出现 Command 列显示成 Killed 的情况。展开作者回复: 1. 一般你执行kill就是要停止正在执行的语句，所以问题不大😋
2. 不应该呀， KILL QUERY 是大写哦，你再grep一下日志；
3. 多提供一种方法嘛。kill query是指你只是想停止这个语句，但是事务不会回滚。一般kill query是发生在客户端执行ctrl+c的时候啦。平时紧急处理确实直接用kill + thread_id。 好问题
4. 对，另外，在kill query无效的时候，其实kill connection也是无效的 1 1 
2019-01-25想咨询一个问题 如果走索引找寻比如age=11的人的时候是只会锁age=10到age=12吗 如果那个索引页包含了从5到13的数据 是只会锁离11最近的还是说二分查找时候每一个访问到的都会锁呢作者回复: 只会锁左右。
1
2019-01-25我想请问下老师，一个事务执行很长时间，我去kill。那么，执行这个事务过程中的数据会不会回滚？作者回复: 这个事务执行过程中新生成的数据吗？ 会回滚的
1
2019-01-25老师，请教一个 第八章 的问题。关于可见性判断，文中都是说事务id大于高水位都不可见。如果等于是不是也不可见。还有一个，readview中是否不包含当前事务id。谢谢老师作者回复: 代码实现上，事务生成trxid后，trxid的分配器会+1，以这个加1以后的数作为高水位，所以“等于”是不算的。
其实有没有包含是一样的，实现上没有包含。 1
2019-01-25想得简单点：既然事务处于回滚状态了，重启MySQL这部分事务还是需要回滚。私以为让它执行完成比较好。 1
2020-01-28kill connection 其实就是关闭了客户端和服务器之间的连接，但是查询还会在继续。show processlist 会将显示为killed，但是后面的执行流程还是会走kill query，所以就是需要等后面的流程去执行了。只能等待。