哎

@huntcool001 没看过源码，但是个人觉得再小粒度上的加锁，其实本质上都是一样的；锁粒度越小，分配管理需要消耗的资源越高，现在的锁应该是兼顾性能，资源且够用的结果

这样永远不会发生死锁，个人观点如下：

1.锁粒度为行级锁，跟是先在主键或者二级索引加锁没关系，此处完全构不成互相等待对方资源释放的情况。
2.这样更新持有锁的时间非常非常非常短，想用这种方法产生互相等待基本不可能，基本是个玄学（记得某本 mysql 相关的书劝过读者，别指望用这种方式跑出相互等待）。

如果想要过的"像个人"，那么是的

上家公司写过

hhahaha ,,,恭喜，开开心心当爹吧

@l00t 怪我观点表述的不够详细。页内查找是在内存中进行的，相对于整个流程来说影响非常小。当单查找某一条数据的时候，或者说查询的数据在同一个数据页的时候，确实像你说的一样，没有变化。但是关系型数据库范围、多条件查找等的情况是非常常见的，这种时候效率确实是有影响的。说白了就是索引查找次数，读盘及 io 的次数不一样。

hahhahah 啊，，，我觉得是电瓶车偷车贼太猖獗的原因造成的

1.关于 varchar 用 text 替换，我想到一个角度就是空间碎片化及重用问题。MySQL 的数据删除在数据页中并不是把数据擦除，而是数据头中的删除标记置为 1，同时标记为可重用。varchar 变长根据需要分配长度，例如插入两条数据，删除第一天，再插入第三条，此时如果第三条的长字段更长的话，空间没法重用。如果大量发生的话，空间的使用效率及碎片化会是个问题。

2.关于索引效率。innodb 对数据的查找的操作最小单位是数据页，先把数据页加载到内存，然后根据页中的稀疏目录及双向链表查找到具体的记录。而索引存储的是数据所在的数据页地址。所以每一个数据页能存储的行数变少后索引效率就低了 @l00t

同志们加油啊，，我 172 少了 1cm 不达标，就看你们的啦。。哈哈哈

秋分就开始凉飕飕了

可以使用 explain extended 加上 show warnings 来查看中间的转换结果

如果是唯一键的话是转化为 join 来进行优化的。所以第二条可以写成：
SELECT b.* FROM b_city b WHERE b.nodeid IN(SELECT a.node_id FROM b_city a)可以转化为

select b.* from b_city b join b_city a where a.nodeid=b.nodeid

@JasonLaw @sdfqwe
select b.* from b_city b where b.nodeid in (select a.nodeid from b_city a)转化为 select b.* from b_city b where
exists(select 1 from b_city a where a.nodeid = b.nodeid);
对于这一条是有问题的。在 5.5 版本之前是这么转化的。但是在 5.6 及后面的版本，MySQL 的优化器对子查询的优化策略是不一样的。
Convert the subquery to a join, or use table pullout and run the query as an inner join between subquery tables and outer tables. Table pullout pulls a table out from the subquery to the outer query