我们现在正在一个平台上工作，我在优化我们的一个查询时遇到了困难，它实际上是一个视图。
在解释查询时，会对我的表执行全表扫描user_role。视图后面的查询看起来像我在下面发布的（我使用 * 代替不同表的不同列，只是为了展示我的问题）。所有结果均基于该简化查询。
SELECT t.*
FROM task t
LEFT JOIN project p ON t.project_id = p.id
LEFT JOIN company comp ON comp.id = p.company_id
LEFT JOIN company_users cu ON cu.companies_id = comp.id
LEFT JOIN user_table u ON u.email= cu.users_email
LEFT JOIN user_role role ON u.email= role.user_email
WHERE lower(t.type) = 'project'
AND t.project_id IS NOT NULL
AND role.role::text in ('SOME_ROLE_1', 'SOME_ROLE_2')
基本上这个查询像这样运行正常。如果我解释查询，它会使用我所有的索引，很好！但是.. 一旦我开始添加额外的 where 子句，问题就出现了。我只是添加这个：
and u.email = 'my@email.com'
and comp.id = 4
and p.id = 3
并且突然在表company_users上user_role执行全表扫描。没有在桌子上project。
完整的查询计划是：
Nested Loop (cost=0.98..22.59 rows=1 width=97) (actual time=0.115..4.448 rows=189 loops=1)
-> Nested Loop (cost=0.84..22.02 rows=1 width=632) (actual time=0.099..3.091 rows=252 loops=1)
-> Nested Loop (cost=0.70..20.10 rows=1 width=613) (actual time=0.082..1.774 rows=252 loops=1)
-> Nested Loop (cost=0.56..19.81 rows=1 width=621) (actual time=0.068..0.919 rows=252 loops=1)
-> Nested Loop (cost=0.43..19.62 rows=1 width=101) (actual time=0.058..0.504 rows=63 loops=1)
-> Index Scan using task_project_id_index on task t (cost=0.28..11.43 rows=1 width=97) (actual time=0.041..0.199 rows=63 loops=1)
Index Cond: (project_id IS NOT NULL)
Filter: (lower((type)::text) = 'project'::text)
-> Index Scan using project_id_uindex on project p (cost=0.15..8.17 rows=1 width=8) (actual time=0.003..0.003 rows=1 loops=63)
Index Cond: (id = t.project_id)
-> Index Scan using company_users_companies_id_index on company_users cu (cost=0.14..0.17 rows=1 width=520) (actual time=0.002..0.004 rows=4 loops=63)
Index Cond: (companies_id = p.company_id)
-> Index Only Scan using company_id_index on company comp (cost=0.14..0.29 rows=1 width=4) (actual time=0.002..0.002 rows=1 loops=252)
Index Cond: (id = p.company_id)
Heap Fetches: 252
-> Index Only Scan using user_table_email_index on user_table u (cost=0.14..1.81 rows=1 width=19) (actual time=0.004..0.004 rows=1 loops=252)
Index Cond: (email = (cu.users_email)::text)
Heap Fetches: 252
-> Index Scan using user_role_user_email_index on user_role role (cost=0.14..0.56 rows=1 width=516) (actual time=0.004..0.004 rows=1 loops=252)
Index Cond: ((user_email)::text = (u.email)::text)
Filter: ((role)::text = ANY ('{COMPANY_ADMIN,COMPANY_USER}'::text[]))
Rows Removed by Filter: 0
Planning time: 2.581 ms
Execution time: 4.630 ms
具体解释company_users如下：
SEQ_SCAN (Seq Scan) table: company_users; 1 1.44 0.0 Parent Relationship = Inner;
Parallel Aware = false;
Alias = cu;
Plan Width = 520;
Filter = ((companies_id = 4) AND ((users_email)::text = 'my@email.com'::text));
但是我已经在表上创建了一个索引company_users：create index if not exists company_users_users_email_companies_id_index on company_users (users_email, companies_id);.
表的计数相同user_role。解释是
SEQ_SCAN (Seq Scan) table: user_role; 1 1.45 0.0 Parent Relationship = Inner;
Parallel Aware = false;
Alias = role;
Plan Width = 516;
Filter = (((role)::text = ANY ('{SOME_ROLE_1,SOME_ROLE_2}'::text[])) AND ((user_email)::text = 'my@email.com'::text));
因此，对于user_role我来说，列上也有一个索引，role并且user_email：create index if not exists user_role_role_user_email_index on user_role (role, user_email);
没想到它会改变任何东西，但无论如何我确实尝试调整查询以在 where 类中仅包含一个角色，并且还尝试使用 OR 语句而不是 IN 但一切都没有区别！
对我来说奇怪的是，如果没有我额外的 3 个过滤器，它可以完美运行，并且一旦我添加它们它就不起作用，但是我确实为解释中提到的字段创建了索引......
我们在其他一些查询中使用完全相同的算法，并且它们在这两个字段上都遇到相同的问题......所以最大的问题是，我如何进一步改进我的查询并使其使用索引而不是完整表扫描？