Obviously, you need to protect the table to make sure that it will not be deleted before your query is executed. Keep in mind that if you start with some kind of table lock to avoid a possible crash - a DROP TABLE query issued from somewhere else will fail with some kind of locking error, or at least wait for your SELECT will not end. Dropping a table is actually often not used, so in most cases the design of the schema is preserved while the server is running - what you observe is a very rare behavior. In the general case, preventing table exclusion due to another query is simply not supported, however in the comments to the document below you can find some trick using semaphore tables to achieve it.
http://dev.mysql.com/doc/refman/5.1/en/lock-tables.html
"Table locking only protects against inappropriate reads or writes by other sessions. A session that holds a lock, even a read lock, can perform table-level operations such as DROP TABLE. Truncate operations are not transactional, so an error occurs if a session tries to perform one operation during an active transaction or hold a table lock. "
"If you need to do something with tables that are not normally supported by read or write locks (like deleting or truncating a table), and you can collaborate, you can try this: use a semaphore table and create two sessions per process. In the first "if necessary, get a read or write lock on the semaphore table. In the second session, do whatever you need to do with all the other tables."
source share