理解本文所需的知识水平：对数据库和 SQL 有一般了解，有一些 DBMS 的实践经验。
![SQL导致的性能问题]()
要编写有效的 SQL 查询，您可以学习的最重要的事情可能就是索引。然而，紧随其后的第二位是许多 SQL 客户端要求数据库执行大量“不必要但必要的工作”的知识。跟着我重复一遍：
什么是“不必要但必须做的工作”？正如 Captain Obvious 告诉我们的那样，她：
![SQL导致的性能问题]()
没什么不寻常的。我们正在使用一个电影数据库（例如Sakila 数据库），并希望向用户显示所有电影的标题和评级。下面的查询可以给出我们需要的结果：
![SQL导致的性能问题]()
在右侧，您甚至可以看到正在加载一些复杂的 JSON：
![Java-университет]()
![SQL导致的性能问题]()
显然，我们正在浪费内存等。让我们将此查询视为替代方案：
请注意，actor 表只有 4 列，因此语句 1 和 2 之间的性能差异并不大，但仍然很显着。我还要指出，我使用 Oracle 优化器提示让优化器为查询选择一个或另一个特定索引。操作员 3 是我们比赛中无可争议的获胜者。它的性能要好得多，而且我们正在讨论一个极其简单的查询。同样，当我们编写 SELECT * 时，我们为数据库创建了不必要但强制性的工作，而数据库无法优化。她不会选择覆盖索引，因为它的开销比她选择的 LAST_NAME 索引稍高，并且除其他外，她仍然必须访问表以检索无用的 LAST_UPDATE 列。但我们分析 SELECT * 越深入，事情就会变得越糟糕。让我们来谈谈...
![SQL导致的性能问题]()
什么，说真的，对吧？现在你开始明白我在说什么了。但想象一下我们从过去的错误中学到了一些东西，并执行这个更优化的查询：
但这并没有发生。优化器（甚至解析器）可以确保 EXISTS 谓词（SELECT ..）中的选择列表元素不会更改查询结果，因此无需执行它。像这样！
| 不必要但必须的工作 |
不必要
让我们的客户端应用程序需要以下数据：
SELECT title, rating
FROM filmSELECT *
FROM film
- 从磁盘
- 缓存
- 电汇
- 为了纪念客户
- 最后扔掉[不必要]
强制的
现在 - 最糟糕的部分。尽管优化器现在可以做很多事情，但这些操作对于数据库来说是强制性的。数据库无法知道客户端应用程序不需要 95% 的数据。这只是最简单的例子。想象一下连接多个表...那么，你会说，数据库速度很快吗？让我来启发您一些您可能没有想到的事情。当然，单个请求的执行时间并不会真正影响任何事情。好吧，它跑得慢了一倍半，但我们会挺过去的，对吧？为了方便？有时这是真的。但如果你总是为了方便而牺牲性能，这些小事情就会开始累积起来。我们将不再谈论性能（单个请求的执行速度），而是谈论吞吐量（系统响应时间），然后就会出现严重的问题，而这些问题并不那么容易解决。那就是你失去可扩展性的时候。让我们看一下执行计划，在本例中是 Oracle DBMS：--------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
--------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 166K|
| 1 | TABLE ACCESS FULL| FILM | 1000 | 166K|
----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
--------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 20000 |
| 1 | TABLE ACCESS FULL| FILM | 1000 | 20000 |
--------------------------------------------------使用索引
如今大多数数据库已经认识到覆盖索引的概念。覆盖索引本身并不是一种特殊类型的索引。但它可能会成为特定查询的“特殊索引”，无论是“偶然”还是因为它本来就是这样的。考虑以下查询：
SELECT *
FROM actor
WHERE last_name LIKE 'A%'-------------------------------------------------------------------
| Id | Operation | Name | Rows |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8 |
| 1 | TABLE ACCESS BY INDEX ROWID| ACTOR | 8 |
|* 2 | INDEX RANGE SCAN | IDX_ACTOR_LAST_NAME | 8 |
-------------------------------------------------------------------
SELECT first_name, last_name
FROM actor
WHERE last_name LIKE 'A%'----------------------------------------------------
| Id | Operation | Name | Rows |
----------------------------------------------------
| 0 | SELECT STATEMENT | | 8 |
|* 1 | INDEX RANGE SCAN| IDX_ACTOR_NAMES | 8 |
----------------------------------------------------SET SERVEROUTPUT ON
DECLARE
v_ts TIMESTAMP;
v_repeat CONSTANT NUMBER := 100000;
BEGIN
v_ts := SYSTIMESTAMP;
FOR i IN 1..v_repeat LOOP
FOR rec IN (
-- Наихудший вариант requestа: перерасход памяти ПЛЮС доступ к таблице
SELECT *
FROM actor
WHERE last_name LIKE 'A%'
) LOOP
NULL;
END LOOP;
END LOOP;
dbms_output.put_line('Оператор 1 : ' || (SYSTIMESTAMP - v_ts));
v_ts := SYSTIMESTAMP;
FOR i IN 1..v_repeat LOOP
FOR rec IN (
-- Улучшенный request, но все равно с доступом к таблице
SELECT /*+INDEX(actor(last_name))*/
first_name, last_name
FROM actor
WHERE last_name LIKE 'A%'
) LOOP
NULL;
END LOOP;
END LOOP;
dbms_output.put_line('Оператор 2 : ' || (SYSTIMESTAMP - v_ts));
v_ts := SYSTIMESTAMP;
FOR i IN 1..v_repeat LOOP
FOR rec IN (
-- Оптимальный request: покрывающий индекс
SELECT /*+INDEX(actor(last_name, first_name))*/
first_name, last_name
FROM actor
WHERE last_name LIKE 'A%'
) LOOP
NULL;
END LOOP;
END LOOP;
dbms_output.put_line('Оператор 3 : ' || (SYSTIMESTAMP - v_ts));
END;
/|
结果我们得到： 接线员 1：+000000000 00:00:02.479000000 接线员 2：+000000000 00:00:02.261000000 接线员 3：+000000000 00:00:01.857000000 |
SQL 转换
优化器表现如此之好，是因为它们转换了 SQL 查询（我最近在苏黎世 Voxxed Days 上的演讲中谈到了它的工作原理）。例如，有一个极其强大的“异常JOIN”转换。考虑以下我们必须创建的辅助视图，以避免每次都手动连接所有这些表：CREATE VIEW v_customer AS
SELECT
c.first_name, c.last_name,
a.address, ci.city, co.country
FROM customer c
JOIN address a USING (address_id)
JOIN city ci USING (city_id)
JOIN country co USING (country_id)SELECT *
FROM v_customer----------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
----------------------------------------------------------------
| 0 | SELECT STATEMENT | | 599 | 47920 | 14 |
|* 1 | HASH JOIN | | 599 | 47920 | 14 |
| 2 | TABLE ACCESS FULL | COUNTRY | 109 | 1526 | 2 |
|* 3 | HASH JOIN | | 599 | 39534 | 11 |
| 4 | TABLE ACCESS FULL | CITY | 600 | 10800 | 3 |
|* 5 | HASH JOIN | | 599 | 28752 | 8 |
| 6 | TABLE ACCESS FULL| CUSTOMER | 599 | 11381 | 4 |
| 7 | TABLE ACCESS FULL| ADDRESS | 603 | 17487 | 3 |
----------------------------------------------------------------
SELECT first_name, last_name
FROM v_customer------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 599 | 16173 | 4 |
| 1 | NESTED LOOPS | | 599 | 16173 | 4 |
| 2 | TABLE ACCESS FULL| CUSTOMER | 599 | 11381 | 4 |
|* 3 | INDEX UNIQUE SCAN| SYS_C007120 | 1 | 8 | 0 |
-------------------------------------------------------------------- Oracle
SELECT CASE WHEN EXISTS (
SELECT 1 / 0 FROM dual
) THEN 1 ELSE 0 END
FROM dual
-- Более адекватные диалекты SQL, например, PostgreSQL
SELECT EXISTS (SELECT 1 / 0)SELECT 1 / 0 FROM dual|
发生： ORA-01476: 除数等于零 |
同时...
ORM 最烦人的问题之一是它们很容易编写 SELECT * 查询。事实上，例如在HQL/JPQL中它们一般都是默认使用的。我们可以完全省略 SELECT 子句，因为我们将检索整个实体，对吧？例如：FROM v_customer计算行数以查明是否存在某些内容
最严重的资源浪费之一是运行 COUNT(*) 查询只是为了查看数据库中是否有某些内容。例如，我们需要查明给定用户是否有订单。我们执行请求：SELECT count(*)
FROM orders
WHERE user_id = :user_id-- Oracle
SELECT CASE WHEN EXISTS (
SELECT *
FROM orders
WHERE user_id = :user_id
) THEN 1 ELSE 0 END
FROM dual
-- Более адекватные диалекты SQL, например, PostgreSQL
SELECT EXISTS (
SELECT *
FROM orders
WHERE user_id = :user_id
)
GO TO FULL VERSION