首先，咱们先揪出你SQL里的一个小细节：你给books表起了别名b，但连接条件里写的是books.author_id = a.id，虽然语法上没问题，但规范起见建议改成b.author_id = a.id，避免后续维护时混淆。

接下来分析为什么Oracle会选择对books表做全表扫描：大概率是因为authors表的过滤条件没有合适的索引，导致Oracle预估符合条件的作者数量过多，或者表的统计信息过时，让成本优化器（CBO）判断全表扫books比走索引更划算。下面是具体的解决步骤：

1. 给authors表的过滤条件建函数索引 #

你的查询用了lower(a.first_name) like 'de%'，普通的first_name索引没法被这个条件利用。创建一个基于lower(first_name)的函数索引：

CREATE INDEX idx_authors_lower_first_name ON authors(lower(first_name));

这个索引能让Oracle快速定位到所有名字以'de'开头（不区分大小写）的作者，大幅减少需要连接的作者ID数量。当符合条件的作者数量很少时，Oracle自然会选择用books的author_id索引来匹配对应的书籍。

2. 收集最新的表和索引统计信息 #

如果你的表统计信息过时，Oracle的成本估算会出错，导致执行计划选择不合理。执行以下命令刷新统计信息（替换成你的实际用户名）：

EXEC DBMS_STATS.GATHER_TABLE_STATS('YOUR_SCHEMA_NAME', 'AUTHORS', CASCADE => TRUE);
EXEC DBMS_STATS.GATHER_TABLE_STATS('YOUR_SCHEMA_NAME', 'BOOKS', CASCADE => TRUE);

CASCADE => TRUE会同时收集索引的统计信息，确保CBO能准确计算索引和全表扫描的成本。

3. 考虑创建覆盖索引（如果回表成本太高） #

如果符合条件的作者数量仍然较多，Oracle可能觉得通过author_id索引找到书籍后，还要回表获取其他字段的成本太高，还是会选择全表扫。这时候可以创建一个覆盖索引，把查询需要的所有字段都包含进去，让Oracle直接从索引获取数据：

-- 替换成你实际需要查询的列，比如title、publish_date等
CREATE INDEX idx_books_author_id_cover ON books(author_id) INCLUDE (title, publish_date, isbn);

这样索引里已经包含了查询所需的所有数据，不需要回表，索引的成本会远低于全表扫描。

4. （可选）用查询提示强制走索引（不推荐优先使用） #

如果以上步骤都试过，Oracle还是固执地选择全表扫描，可以尝试用查询提示引导它使用索引（替换成你的books.author_id索引的实际名称）：

SELECT /*+ INDEX(b idx_books_author_id) */ * 
FROM authors a 
INNER JOIN books b ON b.author_id = a.id 
WHERE lower(a.first_name) like 'de%';

不过要注意，查询提示是强制干预执行计划，可能在数据量变化后变得不适用，所以优先让CBO自己选择更稳妥。

最后，你可以执行EXPLAIN PLAN FOR你的SQL，查看执行计划是否已经切换为使用books的author_id索引，确认优化效果。

内容的提问来源于stack exchange，提问作者sinedsem