MySQL，插入操作与锁关系的一点儿问答

MySQL5.6 innodb 数据库引擎。

有一个大表A，大约8千万条数据。有个业务场景是从A表选出1千万条数据插入B
表，选择语句是走索引的。
1)insert into B(id,name) select id,name from A where id in (11,12,13);
-- id 上有索引。

在这个过程中，线上还有活动业务，有新的数据产生要插入到A表里（B表没有业务
访问），大约要插入1千万条新数据。
2)insert into A(id,name) select id,name from X where xid=XXX; -- 有索引

对于上面的业务场景我是这样分析的：

1.对A表进行查询操作又进行插入操作，我认为不产生锁表A，也不会产生阻塞表
A，不知道对否？
---回答：
---查询操作通常会加读锁
---写入操作通常会加写锁
---如果是UPDATE，必定在对象上（对象可能是元组、物理页、所操作的表等，取决于数据库系统对锁的粒度），除非更新的对象不存在
---如果是INSERT，至少在表对象上加派他锁
---多以对于“2)”语句，至少对X表的“对象”加读锁；对A表的“对象”加派他锁
---上面之所以把“对象”一词用引号括起来，是因为问题相当复杂，深入到内核中，加锁的情况与隔离级别、锁的粒度、与数据库对于并发控制的实现机制有大关系。不宜用短文探讨。
---MySQL的InnoDB支持表锁和行锁

2.由于数据量太大，数据库缓存里原来的热数据会被置换出去。会产生IO操作。
但是我不确定是 insert into B 先完成，还是 insert into A 先完成。
---回答：
---谁先完成，这个说不准的。
---相关的因素有很多。如果数据库支持MVCC，则读写互不阻塞，更不能说哪个更快
---当然，这个问题的前提是在MySQL中。但纵使是MySQL，如果1先开始，1为读A不阻塞2写A；如果2先开始，2为写A可能阻塞1读A

3.对于上面的业务场景，其实会对其他业务产生不良的影响，因为上面的业务场景
会消耗CPU和内存，产生IO，会导致其他业务被阻塞那里，等待，不知道 对否？
---回答：
---当然，会对其他业务产生不良的影响；其他业务也影响问题里的SQL语句。 ^_^
---“会导致其他业务被阻塞那里，等待”，不阻塞除A、B、X表外的读写操作。

4.其实我不太确定上面的业务场景会对这个系统产生什么不良的影响，这个问题问
的可能太宽泛了
---回答：
---其实问问题的朋友已经作答了。如：
---会消耗CPU和内存，产生IO
---“会导致其他业务被阻塞那里，等待”，不阻塞除A、B、X表外的读写操作。