將 WHERE EXISTS (SUBQUERY) 從 MySQL 5.7 遷移到 MARIADB 10.6 后查詢緩慢

Question

我們希望將 LAMP 服務器從 MySQL 5.7 遷移到 MariaDB 10.6。 我們克隆了服務器，安裝了 MariaDB 並遷移了數據庫。 我期待 SQL 查詢的速度有所提高，但令我驚訝的是，我們的應用程序使用 MariaDB 時速度較慢。 我正在嘗試分析一些查詢，我向您展示一個具體案例。

我們有這樣的查詢： (a) SELECT.. FROM.. WHERE EXISTS (SELECT.. FROM.. WHERE outer_col=inner_col AND inner_where)

使用 MySQL 5.7：0.1 秒。 使用 MariaDB 10.6：10s

我嘗試按照此處的建議更改查詢： (b) .. WHERE outer_col IN (SELECT inner_col FROM.. WHERE inner_where)

使用 MySQL 5.7：0.1 秒。 使用 MariaDB 10.6：10s

最后，我嘗試禁用物化優化器開關的默認值： SET SESSION optimizer_switch='materialization=off';

有用。 現在，兩個查詢都使用 MariaDB 持續 0.1 秒。

但為什么？ 這個優化器不應該是一種改進嗎？ 您是否建議永久關閉它？ 我有其他選擇嗎？

我也嘗試了優化器exists_to_in 。 使用exists_to_in=off 和materialization=on 查詢'b' 10s，查詢'a' 0.1s。

謝謝

使用 MySQL 5.7（快速）分析計划

使用 MariaDB 10.6 分析計划，materialization=on 和 exists_to_in=on（慢）

使用 MariaDB 10.6 分析計划，實現 = 關閉（快！）

使用 MariaDB 10.6 分析計划，exists_to_in=off（快！）

CREATE TABLE 總結了相關的行：

CREATE TABLE `GT_CalendariProfessional` (
    `CalendariProfessionalID` BIGINT(20) NOT NULL AUTO_INCREMENT,
    `ProfessionalId` INT(11) NOT NULL,
    `DataInici` DATETIME(6) NOT NULL,
    `DataFi` DATETIME(6) NOT NULL,
    `NecessitatId` INT(11) NULL DEFAULT NULL,
    PRIMARY KEY (`CalendariProfessionalID`) USING BTREE,
    INDEX `ix_professional` (`ProfessionalId`) USING BTREE,
    INDEX `ix_necessitat` (`NecessitatId`) USING BTREE,
    INDEX `ix_outerjoin_nec_dates` (`NecessitatId`, `DataInici`, `DataFi`) USING BTREE,
    INDEX `ix_outerjoin_prof_dates` (`ProfessionalId`, `DataInici`, `DataFi`) USING BTREE,
    INDEX `ix_IdIncidencia` (`IdIncidencia`) USING BTREE,
    CONSTRAINT `FK_GT_CalendariProfessional_GNR_Professionals` FOREIGN KEY (`ProfessionalId`) REFERENCES `GIRH_PROD`.`GNR_Professionals` (`ProfessionalID`) ON UPDATE NO ACTION ON DELETE NO ACTION,
    CONSTRAINT `FK_GT_CalendariProfessional_GT_Necessitat` FOREIGN KEY (`NecessitatId`) REFERENCES `GIRH_PROD`.`GT_Necessitat` (`NecessitatID`) ON UPDATE NO ACTION ON DELETE NO ACTION
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=6423951
;

SELECT COUNT(1) FROM GT_CalendariProfessional => 5413440 行

Answer 1

當你同時擁有INDEX(a)和INDEX(a,b)時，放棄前者； 它分散了優化器使用后者的注意力。 有時這會導致查詢計划緩慢。 （我看到2個這樣的案例。）

我需要查看查詢來判斷我的建議在您的情況下是否重要。 （即使那樣，我可能也不確定。）無論如何，放棄

INDEX `ix_professional` (`ProfessionalId`) USING BTREE,

會將優化器的注意力轉移到

INDEX `ix_outerjoin_prof_dates` (`ProfessionalId`, `DataInici`, `DataFi`) USING BTREE,

這將是“一樣好，也許更好”，但“可能會稍微慢一些”。