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

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

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

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

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

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

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

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

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

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

下面我們來(lái)模擬這種情況：

–會(huì)話一：打開一個(gè)長(zhǎng)事務(wù)