問題背景：
業(yè)務(wù)代碼中, 遇到一個(gè)查詢莫名奇妙少了一些數(shù)據(jù)；

• 通過分析查詢，發(fā)現(xiàn)用了Mysql index merge特性；
• 我試圖將數(shù)據(jù)復(fù)制到另外表，即使建立了類似的索引，即使查詢分析也走了同樣的index merge 依然無法重現(xiàn)；
• 我試圖將原表drop表，再重建該表，這個(gè)問題依然存在；
• 發(fā)現(xiàn)一個(gè)類似的MySql的bug， 已經(jīng)有很多人報(bào)告 https://bugs.mysql.com/bug.php?id=79675 這個(gè)bug似乎在MySql8.0中依然可以重現(xiàn)；
• 還是存在一點(diǎn)區(qū)別，bug報(bào)告中需要禁用 index_merge_intersection 而我這個(gè)case需要禁用 index_merge；

將業(yè)務(wù)代碼最簡(jiǎn)單化抽出來如下：

SELECT
1 as a
FROM
 cty.prmrcmain AS b
WHERE
        b.propertyId IN (
            SELECT
                hId
            FROM
                prmprophistorylord  -- force index (I_prmprophistorylord_hId)
            WHERE
            -- 在cusid 和 hid上分別建立有索引，所以觸發(fā)了index_merge
                            cusId = 39 and hId = 71 
            --下面的UNION ALL語句也 不可缺少，否則無法觸發(fā)這個(gè)case；
            UNION ALL
            SELECT
                hId
            FROM
                prmprophistorytenant
            WHERE
                 1 != 1
        )

解決方案只好禁用相關(guān)特性；
https://dev.mysql.com/doc/refman/5.7/en/switchable-optimizations.html
SELECT @@optimizer_switch\G
SET [GLOBAL|SESSION] optimizer_switch='index_merge=on, index_merge_intersection=off'
目前尚未接到性能問題的報(bào)告