关于mysql source恢复数据过程中，select操作hang

用mysqldump主数据库到文件中，数据库中表的数据比较大，后在备库上用source命令进行恢复，

mysqldump -u root -p dlsp >/DATA/mysql/dump/dump_dlsp.sql

source </DATA/mysql/dump/dump_dlsp.sql

在恢复数据过程中，对要恢复的表进行select操作，该操作就hang了。

用show processlist\G查看了一下;

*************************** 4. row ***************************

     Id: 11

   User: root

   Host: localhost

     db: dlsp

Command: Query

   Time: 334

  State: Waiting for table metadata lock

   Info: select count(1) from LSMP_LOTTERY

select操作在等待表的meta lock

那么是什么导致table meta lock了，原来dump出的文件中会先把要操作的表lock住，直到insert表中的数据都操作完成才释放锁。

dump_dlsp.sql中在insert数据之前，有这样一个操作，LOCK TABLES `LSMP_LOTTERY` WRITE，表的写锁，在释放之前，该表一直处于打开状态，对该表的元数据锁一直会占用。

mysql> show open tables\G;
*************************** 21. row ***************************
   Database: dlsp
      Table: LSMP_LOTTERY
     In_use: 1
Name_locked: 0

这样对表的任何操作(包括DML)，都会被锁住。

附mysql的锁的分类:

1. Meta-data元数据锁：在table cache缓存里实现的，为DDL（Data Definition Language）提供隔离操作。一种特别的meta-data元数据类型，叫Name Lock。（SQL层）
2. 表级table-level数据锁（SQL层） lock table xxxx write(read) 
3. 存储引擎特有机制 — row locks行锁，page locks页锁，table locks表级，版本控制（在引擎中实现）
4. 全局读锁 — FLUSH TABLES WITH READ LOCK（SQL层）

mysql锁的执行流程