Waiting for table阻塞查詢的問題

壹頁書發表於2014-05-09
AI
今天看了一個案例，自己在備庫上做了一下。確實會引起很多問題。
1.一些慢SQL在執行
2.一個終端發出了flush tables命令
3.很多查詢都被阻塞了

假設有兩個慢SQL正在執行，這時發出的flush tables命令被阻塞，
但是後續的查詢重新開啟表，前提條件是所有的執行緒關閉表，但是慢SQL還在執行。
步驟1阻塞了步驟二,步驟二導致步驟三需要等待步驟一。

  1. The thread got a notification that the underlying structure for a table has changed
  2. and it needs to reopen the table to get the new structure.
  3. However, to reopen the table,
  4. it must wait until all other threads have closed the table in question.
  6. This notification takes place if another thread has used FLUSH TABLES
  7. or one of the following statements on the table in question:
  8. FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, orOPTIMIZE TABLE.

大概的情況就是這樣。
在主從讀寫分離的模式下，主庫使用Xtrabackup備份，中間會有一個flush tables with read lock。
如果這個被複制到了從庫，而不巧從庫還有慢SQL，那麼這個問題就很可能出現。
但是使用Xtrabackup備份是否複製flush tables,我還需要進一步實驗。

實驗如下:
終端一執行一個慢SQL

終端二也執行一個慢SQL

終端三執行flush tables,被兩個慢SQL阻塞

終端四的普通查詢被阻塞

終端五的普通查詢被阻塞

檢視上述終端的執行情況


參考:
http://blog.itpub.net/29254281/viewspace-1082297/


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29254281/viewspace-1157701/，如需轉載，請註明出處，否則將追究法律責任。

相關文章