mysql metadata lock锁

　　很多情况下，很多问题从理论上或者管理上而言都是可以避免或者说很好解决的，但是一旦涉及到现实由于管理或者协调或者规范执行的不够到位，就会出现各种各样本不该出现的问题，这些问题的通常在生产环境并不会出现，但是现实是无论在任何环节出现，都得去找到解决方法，很多时候原因是一部分，预防措施也是一部分，但解决方法也是必须的，因为不可能跟所有的开发人员说你按照我说的做就没有问题了，因为总会有人疏忽了或者忽视了。

　　前两天，测试环境升级脚本，跑到一半就报锁超时了，好几次后测试让协助而解决下。看了下，是个truncate操作在获取metadata lock，这个环境很复杂，有十来个应用连接着，有些是直接从仿真线路接进来的，测试、开发也都不想把应用停了，不然折腾太麻烦。默认该环境的锁超时时间是60s，同时设置了非autocommit，有个查询被truncate表的应用（这是后来知道的）不停的在查询该表，因为查询也需要metadata lock，除非commit或者rollback。在解决的过程中，最大的技术问题在于Mysql 5.7之前mysql原生无法看到metadata lock的阻塞者信息，导致逐个应用确认花费了时间（对于5.7的metadata_locks一直是有印象的，但发现5.6没有），但开发也不知道到底哪些应用会查询或者DML该表。最后临时性将autocommit设置为1，同时把锁超时时间设置为3600秒，两分钟后升级完过去。

在mysql 5.7开始，可通过下述方法查询Metadata lock的持有者和阻塞者：

UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME ='global_instrumentation';

UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME ='wait/lock/metadata/sql/mdl';

SELECT ml.*,thr.* FROM `metadata_locks` ml,threads thr
WHERE ml.`OWNER_THREAD_ID` = thr.`THREAD_ID`;

*************************** 1. row ***************************
          OBJECT_TYPE: TABLE
        OBJECT_SCHEMA: performance_schema
          OBJECT_NAME: metadata_locks
OBJECT_INSTANCE_BEGIN: 240554768
            LOCK_TYPE: SHARED_READ
        LOCK_DURATION: TRANSACTION
          LOCK_STATUS: GRANTED
               SOURCE: sql_parse.cc:5927
      OWNER_THREAD_ID: 38
       OWNER_EVENT_ID: 10
1 row in set (0.00 sec)

对于mysql 5.6，可以考虑mariadb开发的mysql-plugin-mdl-info插件，可以查看类似信息。