線程長(zhǎng)時(shí)間處于killed狀態(tài)怎么辦?

一、線程長(zhǎng)時(shí)間處于killed狀態(tài)怎么辦

如果一個(gè)線程被標(biāo)記為kill或query end，并且 InnoDB 引擎狀態(tài)報(bào)告同一線程的回滾，請(qǐng)等待它結(jié)束。它可能與從磁盤中刪除一些臨時(shí)表有關(guān)。一個(gè)ALTER TABLE可能需要丟棄非常大的臨時(shí)表，而某些文件系統(tǒng)（例如ext3或ext4）刪除大文件可能相當(dāng)慢。

因此可能需要幾秒鐘甚至更長(zhǎng)的時(shí)間。任何 DML 語(yǔ)句也可以創(chuàng)建臨時(shí)表，但通常不會(huì)那么大。

在最極端的情況下，刪除文件也不會(huì)超過(guò)十或二十秒，但在 I/O 負(fù)載較重的情況下，它可能會(huì)更長(zhǎng)，所以有什么方法可以查看是否有臨時(shí)表是否被創(chuàng)造？在Percona Server或MariaDB中，您檢查INFORMATION_SCHEMA.GLOBAL_TEMPORARY_TABLE和INFORMATION_SCHEMA.TEMPORARY_TABLE的內(nèi)容。它僅適用于使用CREATE TEMPORARY TABLE語(yǔ)句手動(dòng)建立的臨時(shí)表，不適用于 MySQL 隱式創(chuàng)建的執(zhí)行復(fù)雜查詢時(shí)的臨時(shí)表。

延伸閱讀：

二、行式數(shù)據(jù)庫(kù)與列式數(shù)據(jù)庫(kù)應(yīng)用場(chǎng)景

行式更適合OLTP，比如傳統(tǒng)的基于增刪改查操作的應(yīng)用。列式更適合OLAP，非常適合于在數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域發(fā)揮作用，比如數(shù)據(jù)分析、海量存儲(chǔ)和商業(yè)智能；涉及不經(jīng)常更新的數(shù)據(jù)。

由于設(shè)計(jì)上的不同，列式數(shù)據(jù)庫(kù)在并行查詢處理和壓縮上更有優(yōu)勢(shì)。而且數(shù)據(jù)是以列為單元存儲(chǔ)，完全不用考慮數(shù)據(jù)建模或者說(shuō)建模更簡(jiǎn)單了。要查詢計(jì)算哪些列上的數(shù)據(jù)，直接讀取列就行。

最后我們需要?jiǎng)?wù)實(shí)的指出，沒(méi)有使用廣泛的數(shù)據(jù)庫(kù)，列式數(shù)據(jù)庫(kù)也并非使用廣泛，只不過(guò)給DBA提供了更多的選擇，DBA需根據(jù)自己的應(yīng)用場(chǎng)景自行選擇。