我在Oracle 11g上，我们有以下3个核心表：
Customer - CUSTOMERID|DOB
CustomerName - CUSTOMERNAMEID|CustomerID|FNAME|LNAME
Address - ADDRESSID|CUSTOMERID|STREET|CITY|STATE|POSTALCODE
我在每张表上都有大约6000万行，数据是美国和加拿大人口的混合数据。
我有一个前端应用程序，它调用web服务，他们会进行姓氏和部分zip搜索。所以我的查询基本上有
where CUSTOMERNAME.LNAME = ? and ADDRESS.POSTALCODE LIKE '?%'
它们通常提供zip的前3位数字。
地址表有一个关于所有街道/城市/州/邮编的索引，另一个关于州和邮编的索引。
我确实尝试添加了一个专门用于zip的索引，并强制oracle在我的查询中使用该索引，但这并没有任何区别。
对于返回大约100行(我有分页，一次只返回100行)，大约需要30秒，这并不理想。我能做些什么来使这更好？
问题是您正在应用的筛选器不是很有选择性，它们应用于不同的表。这对于老式的btree指数来说是不好的。如果内容非常静态，您可以尝试位图索引。更确切地说，是基于函数的位图连接索引，位于姓氏的前三个字母上，位图连接索引位于邮政编码列上。这是假设居住在中的姓氏以特定字母开头的人很少有特定的邮政编码。
CREATE BITMAP INDEX ix_customer_custname ON customer(SUBSTR(cn.lname,1,3))
FROM customer c, customername cn
WHERE c.customerid = cn.customerid;
CREATE BITMAP INDEX ix_customer_postalcode ON customer(SUBSTR(a.postalcode,1,3))
FROM customer c, address a
WHERE c.customerid = a.customerid;
如果成功，您应该看到两个位图索引变成AND连接。执行时间应该减少到几秒钟。它不会像btree索引那样快。
备注：
您可能需要考虑一下制作一个或两个索引是否更有效，以及该函数是否有用。
如果您决定基于函数执行，则应在查询的where子句中包含完全相同的函数调用。否则将不使用索引。
DML的运作将相当缓慢。这只对具有静态数据的表有用。注意，DML操作将阻止整行的"范围"。并发DML操作将遇到问题。
响应时间可能仍然是秒，不像BTREE指数那样即时。
AFAIK这将只适用于企业版。该语法未经测试，因为我目前没有可用的企业数据库。
如果这还不够快，你可以创建一个带有customerid、姓氏和邮政编码的物化视图，但上面有一个btree索引。但这也有点昂贵。