公司最近要做类似关注与粉丝的功能，需要将之前已经加为好友或者已经提交好友请求的数据转化为follow关系，我设计了两个表，follow和fan，同时在user_info表中添加了follow_count和fan_count两个字段，在功能上线之前，需要将现网的数据导出，然后转化为foll
公司最近要做类似关注与粉丝的功能，需要将之前已经加为好友或者已经提交好友请求的数据转化为follow关系，我设计了两个表，follow和fan，同时在user_info表中添加了follow_count和fan_count两个字段，在功能上线之前，需要将现网的数据导出，然后转化为follow关系再导入，总数据为75万条（社区刚放开，还没有大规模推广）。
策略1：
根据导出的经过排序的uid来操作，一共75万insert操作，75万update操作，整理写成sql文件， 直接cat sql | mysql 执行，居然一个下午都没有完成，通过show processlist发现没死，还在一个一个执行，只能中断操作
策略2：
将策略1生成的sql请求分成10份，有点并行操作的意思，结果还是一下午没有做完（其实没有从本跟上解决问题）
策略3：
经过分析，确定问题肯定在随机uid的insert和update操作使得mysql频繁的跨库跨表lock table和unlock taoble，时间都花费在表的切换上了。于是决定将操作按照db和table进行分类， 采用了multimap结构，
multimap insert_query;
multimap update_query;
以db_xx.table_xx为key，value就是要执行的sql，这样生成了两个sql：insert.sql和update.sql, 执行结果：
insert complete --- sns_user_97.user_follow_96
insert complete --- sns_user_97.user_follow_97
insert complete --- sns_user_97.user_follow_98
insert complete --- sns_user_97.user_follow_99
insert complete --- sns_user_98.user_follow_00
insert complete --- sns_user_98.user_follow_01
insert complete --- sns_user_98.user_follow_02
insert complete --- sns_user_98.user_follow_03
insert complete --- sns_user_98.user_follow_04
insert complete --- sns_user_98.user_follow_05
insert complete --- sns_user_98.user_follow_06
insert complete --- sns_user_98.user_follow_07
可以清晰的看到，顺序执行sql操作使得lock table造成的消耗降到了最低，最终结果：
update 1分钟内完成
insert 10分钟完成
策略4：
将策略3的结果sql按照key分成N块，起N个进程并行执行，这样会在1分钟之内完成，因为不同的表根本不会有锁的进程，效率提升会又上一个量级
从这个经验我想到了两点：
1.任务的队列化，如果任务的执行会涉及到大范围的随机跳转操作，而这种跳转还会引起资源竞争，那么最好的办法就是将任务队列化，按照跳转最少，资源竞争最少的原则进行排序。
2.在任务队列化的基础上，map/reduce
(备注：咱机器不行，大家不要太在意那个10分钟的时间消耗，我只是说有下这种思路，希望大家多多拍砖)
