DBMS_CRYPTO性能问题

Question

在数据库泄露的情况下，我使用DBMS_CRYPTO来保护信息。密钥不存储在dbms中，而是由应用程序在每次访问时提供。

select decrypt(name), seq order by seq查询所需时间(几乎精确)是两者之一的15倍

select decrypt(name), seq

或

select name, seq order by seq

这使我相信解密函数正在破坏主密钥seq上的索引。它为什么会破裂？

我尝试将关键字DETERMINISTIC添加到函数的输出类型中，但它只将时间缩短到大约比快速查询长10倍。我不明白为什么要花比select decrypt(name), seq更长的时间。编辑：DETERMINISTIC关键字也加快了简单解密查询的速度，正如我们所期望的那样。

我的期望是错的，还是别的什么？考虑到安全方面的限制，我可以延迟300 is，但3000 is是值得注意的，我想让它更快一些。

我使用的是一个名为SmartSQL的DB工具，它提供了一个“时间流逝”显示(假设从发送查询到接收最后一点结果之间的时间)。

在seq上有一个索引，即主键。我认为在加密的值上放置索引是没有帮助的。

执行计划：

选择解密(名称)，seq

------------------------------------------------------------------------------------
| Id  | Operation         | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                |  8810 |  1453K|    98   (3)| 00:00:02 |
|   1 |  TABLE ACCESS FULL| CSTN_MEMB_INFO |  8810 |  1453K|    98   (3)| 00:00:02 |
------------------------------------------------------------------------------------

选择名称，seq顺序按seq desc

---------------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |  8810 |  1453K|       |   428   (1)| 00:00:06 |
|   1 |  SORT ORDER BY     |                |  8810 |  1453K|  3448K|   428   (1)| 00:00:06 |
|   2 |   TABLE ACCESS FULL| CSTN_MEMB_INFO |  8810 |  1453K|       |    98   (3)| 00:00:02 |
---------------------------------------------------------------------------------------------

选择解密(名称)，seq顺序由seq desc

---------------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |  8810 |  1453K|       |   428   (1)| 00:00:06 |
|   1 |  SORT ORDER BY     |                |  8810 |  1453K|  3448K|   428   (1)| 00:00:06 |
|   2 |   TABLE ACCESS FULL| CSTN_MEMB_INFO |  8810 |  1453K|       |    98   (3)| 00:00:02 |
---------------------------------------------------------------------------------------------

我的完整查询如下：

select 
    seq, gender, wdate, address, 
    my_crypto_pkg.decrypt(tel, 'my_secret_key'), 
    my_crypto_pkg.decrypt(name, 'my_secret_key') 
from cstn_memb_info
--  where my_crypto_pkg.decrypt(name, 'my_secret_key') like ?
order by
    seq desc

Answer 1

只要注释掉涉及解密数据的谓词，返回第一行的时间对于这三个查询就会有很大的不同。但考虑到你想要达到的最终结果，这似乎没有什么意义。

如果消除了decrypt调用，那么只需扫描表，就不必调用单独的函数来解密数据(这比仅仅读取数据要昂贵得多)。如果消除了ORDER BY，Oracle只需在返回数据之前对前N行进行解密，甚至不必完成对表的扫描。如果对数据进行解密并对结果排序，则必须先解密所有数据，然后才能进行排序，并开始返回结果。对于同时执行decrypt和ORDER BY的查询，获取最后一行的时间也将最长，但差异要小得多。一旦在已解密的值上添加谓词，所有查询的速度至少都应该与三个查询中最慢的一个一样慢，这与您最终想要运行的查询更加一致。

实际上，由于您打算对已解密的值有一个谓词，并且由于加密密钥是在运行时传入的，所以在对结果排序之前，您必须对表进行完整扫描，对每一行进行解密。随着数据量的增加，这将是相当缓慢的。当您谈论“分页视图”时，它通常也与您描述的内容不兼容。由于每次运行此查询时都必须解密每一行，所以不希望编写返回前10行的查询，然后发出另一个查询以获取11-20行等。每次获取一页数据时，都需要重新解密表中的每一行。

如果您使用的是11g，那么使用结果缓存功能可能会允许您发出单独的查询，以合理有效的方式获取单个页面的数据。但这在10g中是没有的。