一個簡單的DDL操作(表資料很少，訪問高)執行很久，導致Waiting for table metadata lock。

版本：mysql5.5.17

檢視：Innodb_buffer_pool_pages_free = 0

解決：set global innodb_stats_on_metadata=0

這個問題來自冷之同學測試時候碰到的一個“詭異現象”。

1、 測試現象       

測試的庫有很多資料，但是重啟之後，只對一個表的5w條記錄作查詢。查詢條件客戶端控制，確保查詢範圍。innodb_buffer_pool_size設定為35G。

現象1：查詢效能會出現大幅度抖動；

現象2：介入追查後發現，Innodb_buffer_pool_pages_free = 0

         其中bp剩餘量這個是最直觀異常的，因為訪問的5w行記錄撐死也不可能把35G記憶體吃光的。在QA同學確認沒有別人在使用這個庫的情況下。

2、過程和原因

         其實幾乎確定還是有別的查詢在訪問的。所以開啟general_log。 發現除了QA同學壓的語句外，這個Server上還有一些監控語句。

         其中一個語句如下

select constraint_schema,table_name,constraint_name,constraint_type from information_schema.table_constraints where table_schema not in ('information_schema', 'mysql', 'test');  

         這個語句訪問了表 information_schema.table_constraints.

跟蹤發現這個語句觸發了讀盤操作。原因是需要訪問引擎的info()介面，而InnoDB此時又“順手”做了更新索引統計的操作dict_update_statistics。

更新索引統計的基本流程是隨機讀取部分demo行。所以這個操作實際上是訪問了這個Server裡面的所有表，因此不只是訪問5w行。

而且由於別的表事先沒有被訪問，就會導致讀盤操作，也包括BP的LRU更新。

3、哪些表會觸發

         不只是上面提到的table_constraints，information_schema庫下的一下幾個表，訪問時候都會觸發這個“順手”操作。

information_schema.TABLES

information_schema.STATISTICS

information_schema.PARTITIONS

information_schema.KEY_COLUMN_USAGE

information_schema.TABLE_CONSTRAINTS

information_schema.REFERENTIAL_CONSTRAINTS

         其實還有 show table status ，也會觸發這個操作，只是只處理單表，所以影響沒那麼明顯。

4、修改

頭痛醫頭的方法是把這些監控去掉。但實際上像TABLES、TABLE_CONSTRAINTS這些表，都是靜態資料，訪問時不作索引統計也沒關係的。

另外一個方法就是把innodb_stats_on_metadata設定成off，這樣上述說到的這些表訪問都不會觸發索引統計。

         實際上這個動態統計的功能已經不推薦了，官方已經在6.0以後增加引數控制DML期間也不作動態統計了。因此這個引數配置成off更合理些（預設是on）