If you run the INSERT statements with a LOCK TABLES table_name WRITE before doing the inserts, then, no, it won't because the DROP INDEX will have to wait for the inserts to complete. Otherwise, in the default AUTOCOMMIT mode set to 1, the DROP INDEX would execute "in between" inserts, and possibly cause locking.
Note: If you took my advice above on using INSERT DELAYED, *don't* use LOCK TABLES, as INSERT DELAYED uses a separate thread.
This kind of situation is a bit tricky and will require you to find a good balance of if, when and how often to recreate indexes or use ANALYZE TABLE. It will require you to benchmark a couple scenarios and see what works best for your situation... You may want to leave the index in there and try the batch inserts normally; if performance suffers, try dropping the index before and re-creating the index after the inserts. Use LOCK TABLES table_name WRITE; before either to ensure that you lock the table for as little time as possible and give priority to write operations. Also ensure that SET AUTOCOMMIT=0; at the start of your session.
I'd highly recommend running some benchmarks on a test system to determine what's best in this scenario. It might work out that you do an ANALYZE TABLE at a regularly scheduled interval (during off-peak hours) and leave the index intact during inserts...
Hope this is what you were looking for,
Jay Pipes
Community Relations Manager, North America, MySQL Inc.
Got Cluster?
http://www.mysql.com/cluster
Personal:
http://jpipes.com