最近剛寫了一篇文章介紹了下長事務(wù)，以及一些長事務(wù)常見的危害，如無法及時的垃圾回收導(dǎo)致表膨脹之類的問題，最近剛好又碰到一個問題也是長事務(wù)所導(dǎo)致的。

上周六早上接到同事電話，說某個庫CPU一直很高，看了下全是某張大表的全表掃描導(dǎo)致，但是奇怪的是相關(guān)的查詢都有用到索引列，不知道為啥查詢?nèi)慷紱]走索引。

當我連上去查看時發(fā)現(xiàn)確實如此，如果只是某個查詢不走索引那可能是SQL本身寫的有問題，但是這張表相關(guān)的所有SQL都不走索引，那自然會想到是索引本身的原因了。那是不是索引失效了呢？經(jīng)過檢查發(fā)現(xiàn)這張表上的索引狀態(tài)均正常，并且我還將索引重建了，可仍然沒起作用。

正當我迷茫的時候，偶然間再去執(zhí)行相關(guān)SQL的時候發(fā)現(xiàn)竟然又都走索引了，這又是啥情況。。

我啥都沒做你就自己恢復(fù)了，那不是顯得我很呆？不行，必須得搞清楚啥原因。

當我再去查看相關(guān)索引的時候發(fā)現(xiàn)，該索引的pg_index中的indcheckxmin列均為true，這個字段我之前有寫過一篇索引失效的文章里介紹過。那么什么情況下索引的該屬性會被設(shè)置為true呢？兩種情況：

1. 當前事務(wù)中表上存在broken HOT chains；
2. 當old_snapshot_threshold被設(shè)置時。

之前我們也介紹過，如果索引的該屬性為true那么在創(chuàng)建索引的事務(wù)中該索引是不可用的，不過這種場景我們基本不太會遇到，因為在實際應(yīng)用中我們基本不會在事務(wù)中創(chuàng)建完索引然后不提交該事務(wù)直接去使用。

而關(guān)于indcheckxmin的詳細解釋是：直到此pg_index行的xmin低于查詢的TransactionXmin之前，查詢都不能使用此索引。那么什么情況下會出現(xiàn)這種問題呢？長事務(wù)！

當我們創(chuàng)建索引的時候如果索引的indcheckxmin被設(shè)置為true，且數(shù)據(jù)庫中此時存在長事務(wù)，那么直到該長事務(wù)提交前，該索引會一直不可用。

下面我們來模擬這種情況：

–會話一：打開一個長事務(wù)