最近我们将Redmine的MySql版本从5.7升级到8.0.32。升级后，MyPage 查询需要很长时间才能执行（大约 1 分钟）。之前在 5.7 版本中，它通常在几秒钟内执行。
初步研究看来，MySql 8 使用派生查询优化概念，因此 5.7 和 8 中解释查询的逻辑是不同的。
Redmine版本：4.1.1.stable（在最新的redmine版本5.0.5上尝试过，但遇到了同样的问题。所有适当的索引也已完成）
我的页面查询：
SELECT
issues.id AS t0_r0,
issues.tracker_id AS t0_r1,
issues.project_id AS t0_r2,
issues.subject AS t0_r3,
issues.description AS t0_r4,
issues.due_date AS t0_r5,
issues.category_id AS t0_r6,
issues.status_id AS t0_r7,
issues.assigned_to_id AS t0_r8,
issues.priority_id AS t0_r9,
issues.fixed_version_id AS t0_r10,
issues.author_id AS t0_r11,
issues.lock_version AS t0_r12,
issues.created_on AS t0_r13,
issues.updated_on AS t0_r14,
issues.start_date AS t0_r15,
issues.done_ratio AS t0_r16,
issues.estimated_hours AS t0_r17,
issues.parent_id AS t0_r18,
issues.root_id AS t0_r19,
issues.lft AS t0_r20,
issues.rgt AS t0_r21,
issues.is_private AS t0_r22,
issues.position AS t0_r23,
issues.remaining_hours AS t0_r24,
issues.story_points AS t0_r25,
issues.closed_on AS t0_r26,
issue_statuses.id AS t1_r0,
issue_statuses.name AS t1_r1,
issue_statuses.is_closed AS t1_r2,
issue_statuses.position AS t1_r3,
issue_statuses.default_done_ratio AS t1_r4,
projects.id AS t2_r0,
projects.name AS t2_r1,
projects.description AS t2_r2,
projects.homepage AS t2_r3,
projects.is_public AS t2_r4,
projects.parent_id AS t2_r5,
projects.created_on AS t2_r6,
projects.updated_on AS t2_r7,
projects.identifier AS t2_r8,
projects.status AS t2_r9,
projects.lft AS t2_r10,
projects.rgt AS t2_r11,
projects.inherit_members AS t2_r12,
projects.default_version_id AS t2_r13,
projects.default_assigned_to_id AS t2_r14
FROM
issues
INNER JOIN projects ON projects.id = issues.project_id
INNER JOIN issue_statuses ON issue_statuses.id = issues.status_id
LEFT OUTER JOIN enumerations ON enumerations.id = issues.priority_id
WHERE
(projects.status <> 9
AND EXISTS (
SELECT 1
FROM enabled_modules em
WHERE em.project_id = projects.id AND em.name='issue_tracking'
))
AND (
issues.status_id IN (SELECT id FROM issue_statuses WHERE is_closed=FALSE)
AND issues.assigned_to_id IN ('1051', '2643')
AND projects.status IN ('1')
)
ORDER BY
enumerations.position DESC,
issues.updated_on DESC,
issues.id DESC
LIMIT 10;
MySQL 8.0.32 的解释
| id | 选择类型 | 桌子 | 分区 | 类型 | 可能的键 | 键 | key_len | 参考 | 行 | 过滤 | 额外 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 简单 | 问题状态 | 全部 | 小学 | 19 | 100 | 临时使用；使用文件排序 | ||||
| 1 | 简单 | 问题状态 | eq_ref | 主要，index_issue_statuses_on_is_close | 小学 | 4 | deermine.issue_statuses.id | 1 | 89.47 | 使用地点 | |
| 1 | 简单 | 全部 | 100 | 使用地点；使用连接缓冲区（哈希连接） | |||||||
| 1 | 简单 | 项目 | eq_ref | 小学 | 小学 | 4 | .project_id | 1 | 9 | 使用地点 | |
| 1 | 简单 | 问题 | 参考 | issues_project_id、index_issues_on_status_id、index_issues_on_assigned_to_id | 问题_项目_id | 4 | .project_id | 1917 | 0.03 | 使用地点 | |
| 1 | 简单 | 枚举 | eq_ref | 主要，index_enumerations_on_id_and_type | 小学 | 4 | deermine.issues.priority_id | 1 | 100 | ||
| 2 | 物化 | 他们 | 全部 | enabled_modules_project_id | 3545 | 10 | 使用地点 |
MySQL 5.7 的解释
| id | 选择类型 | 桌子 | 分区 | 类型 | 可能的键 | 键 | key_len | 参考 | 行 | 过滤 | 额外 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 小学 | 问题 | 范围 | issues_project_id、index_issues_on_status_id、index_issues_on_assigned_to_id | index_issues_on_signed_to_id | 5 | 2560 | 100 | 使用索引条件；使用临时的；使用文件排序 | ||
| 1 | 小学 | 问题状态 | eq_ref | 主要，index_issue_statuses_on_is_close | 小学 | 4 | deermine.issues.status_id | 1 | 89.47 | 使用地点 | |
| 1 | 小学 | 问题状态 | eq_ref | 小学 | 小学 | 4 | deermine.issues.status_id | 1 | 100 | ||
| 1 | 小学 | 枚举 | eq_ref | 主要，index_enumerations_on_id_and_type | 小学 | 4 | deermine.issues.priority_id | 1 | 100 | ||
| 1 | 小学 | 项目 | eq_ref | 小学 | 小学 | 4 | deermine.issues.project_id | 1 | 9 | 使用地点 | |
| 2 | 依赖子查询 | 他们 | 参考 | enabled_modules_project_id | enabled_modules_project_id | 5 | deermine.projects.id | 5 | 10 | 使用地点 |
如您所见，在 5.7 中，所有行都在单个查询中提取，而在 8.0.32 中，它在多个查询中提取。
有什么办法可以解决这个问题吗？
我们通过关闭 MySQL 8 中的 optimizer_switch 中的“物化”开关来解决此问题。关闭物化开关后，SQL 不会为 where contains 条件创建临时表，从而加快查询执行速度。
执行时间从 1 分钟以上下降到不到 1 毫秒。