insert …select …帶來的問題
當使用insert...select...進行記錄的插入時，如果select 的表是innodb 類型的，不論insert 的表是什麼類型的表，都會對select 的表的紀錄進行鎖定。
對於那些從oracle 遷移過來的應用，需要特別的注意，因為oracle 並不存在類似的問題，所以在Oracle 的應用中insert...select...操作非常的常見。例如：有時候會對比較多的紀錄進行統計分析，然後將統計的中間結果插入到另外一個表，這樣的操作因為進行的非常少，所以可能並沒有設置相應的索引。如果遷移到MySQL數據庫後不進行相應的調整，那麼在進行這個操作期間，對需要select 的表實際上是進行的全表掃描導致的所有記錄的鎖定，將會對應用的其他操作造成非常嚴重的影響。
究其主要原因，是因為MySQL 在實現復制的機制時和Oracle 是不同的，如果不進行select 表的鎖定，則可能造成從數據庫在恢復期間插入結果集的不同，造成主從數據的不一致。如果不采用主從復制，關閉binlog 並不能避免對select 紀錄的鎖定，某些文檔中提到可以通過設置innodb_locks_unsafe_for_binlog 來避免這個現象，當這個參數設置為true 的時候，將不會對select 的結果集加鎖，但是這樣的設置將可能帶來非常嚴重的隱患。如果使用這個binlog 進行從數據庫的恢復，或者進行主數據庫的災難恢復，都將可能和主數據庫的執行效果不同。
因此，我們並不推薦通過設置這個參數來避免insert...select...導致的鎖，如果需要進行可能會掃描大量數據的insert...select 操作，我們推薦使用select...into outfile 和load data infile 的組合來實現，這樣是不會對紀錄進行鎖定的。
