【原】mysql的for update优化心得

一个消息表，需要被多个节点抓取，存在并发的情况，要求节点抓取的数据不能重复。

结论：可以解决需求，但会导致表锁，原因是for update只有在限制主键ID时，才会采用行锁，否则会采用表锁。所以要使用for update，必须限制查询表的主键ID。

结论：不能解决问题，且会造成 DEPENDENT SUBQUERY ，从而导致慢查询。原因是子查询的查询次数依赖于外层查询，当外查询数据过多时，会严重影响查询性能。

结论：不会造成慢查询，但会造成数据重复抓取。原因是临时表的查询没有采用 for update ，依然可以读取到正在修改的数据，所以当有并发请求时，可能会取到已被修改过的数据，造成脏读。

结论：能满足需求，且在百万级数据下仍然做到毫秒级查询(当然也跟机器配置有关)。

希望能帮到有需要的人。

第一优化你的sql和索引；

第二加缓存，memcached,redis；

第三以上都做了后，还是慢，就做主从复制或主主复制，读写分离，可以在应用层做，效率高，也可以用三方工具，第三方工具推荐360的atlas,其它的要么效率不高，要么没人维护；

第四如果以上都做了还是慢，不要想着去做切分，mysql自带分区表，先试试这个，对你的应用是透明的，无需更改代码,但是sql语句是需要针对分区表做优化的，sql条件中要带上分区条件的列，从而使查询定位到少量的分区上，否则就会扫描全部分区，另外分区表还有一些坑，在这里就不多说了；

第五如果以上都做了，那就先做垂直拆分，其实就是根据你模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统；

第六才是水平切分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的sharding key,为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带sharding key，将数据定位到限定的表上去查，而不是扫描全部的表；

---