如查询执行计划中所述,SQL 编译器会将 SQL 语句转换为查询执行计划,以用于获取查询结果。本页面介绍了构造 SQL 语句的最佳实践,帮助 Spanner 找到高效的执行计划。
本页中显示的示例 SQL 语句使用以下示例架构:
GoogleSQL
CREATE TABLE Singers (
SingerId INT64 NOT NULL,
FirstName STRING(1024),
LastName STRING(1024),
SingerInfo BYTES(MAX),
BirthDate DATE
) PRIMARY KEY (SingerId);
CREATE TABLE Albums (
SingerId INT64 NOT NULL,
AlbumId INT64 NOT NULL,
AlbumTitle STRING(MAX),
ReleaseDate DATE
) PRIMARY KEY (SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
PostgreSQL
CREATE TABLE Singers (
SingerId BIGINT PRIMARY KEY,
FirstName VARCHAR(1024),
LastName VARCHAR(1024),
SingerInfo BYTEA,
BirthDate TIMESTAMPTZ
);
CREATE TABLE Albums (
SingerId BIGINT NOT NULL,
AlbumId BIGINT NOT NULL,
AlbumTitle VARCHAR(1024),
ReleaseDate DATE,
PRIMARY KEY(SingerId, AlbumId),
FOREIGN KEY (SingerId) REFERENCES Singers(SingerId)
) INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
如需了解详情,请参阅 Spanner 中的 PostgreSQL 语言。
使用查询参数
在使用用户输入构建查询时,Spanner 支持使用查询参数来提高性能,并且有助于防止 SQL 注入。您可以使用查询参数替换任意表达式,但不能替换标识符、列名称、表名或查询的其他部分。
参数可以出现在需要字面量值的任何位置。同一个参数名称可以在单个 SQL 语句中多次使用。
总的来说,查询参数通过以下方式支持查询执行:
- 预先优化的计划:每次调用时,系统都可以更快地执行使用参数的查询,因为参数化可让 Spanner 更轻松地缓存执行计划。
- 简化了查询组合:在查询参数中提供字符串值时,无需对其进行转义。查询参数还可以降低语法错误的风险。
- 安全性:查询参数保护您免受各种 SQL 注入攻击,使您的查询更加安全。这种保护对于根据用户输入构造的查询尤其重要。
了解 Spanner 如何执行查询
Spanner 允许您使用声明式 SQL 语句来查询数据库,这些语句指定要检索的数据。如果您想了解 Spanner 如何获取结果,请检查查询的执行计划。查询执行计划显示与查询的每个步骤相关的计算费用。利用这些开销信息,您可以调试查询性能问题并优化查询。如需了解详情,请参阅查询执行计划。
您可以通过 Google Cloud 控制台或客户端库检索查询执行计划。
如需使用 Google Cloud 控制台获取特定查询的查询执行计划,请按以下步骤操作:
打开 Spanner 实例页面。
选择 Spanner 实例名称和要查询的数据库。
点击左侧导航面板中的 Spanner Studio。
在文本字段中输入查询,然后点击 Run query。
点击说明
。Google Cloud 控制台会显示查询的直观执行计划。
如需详细了解如何了解直观计划并使用它们来调试查询,请参阅使用查询计划可视化工具调整查询。
您还可以查看历史查询计划的示例,并比较特定查询在一段时间内的查询性能。如需了解详情,请参阅示例查询计划。
使用二级索引
与其他关系型数据库一样,Spanner 提供二级索引,您可以使用二级索引来通过 SQL 语句或 Spanner 的读取接口检索数据。从索引中提取数据的更常见方法是使用 Spanner Studio。在 SQL 查询中使用二级索引的好处在于,您可以指定希望 Spanner 获取结果的方式。 指定二级索引可以加快查询执行速度。
例如,假设您想要提取具有特定姓氏的所有歌手的 ID。可按照如下方法编写这样一个 SQL 查询:
SELECT s.SingerId
FROM Singers AS s
WHERE s.LastName = 'Smith';
此查询将返回您期望的结果,但需要的时间可能很长,具体取决于 Singers
表中的行数以及满足谓词 WHERE s.LastName = 'Smith'
的行数。如果没有包含要读取的 LastName
列的二级索引,那么查询计划将读取整个 Singers
表来查找与谓词相匹配的行。读取整个表的过程称为“全表扫描”。当表中仅包含一小部分具有该姓氏的 Singers
时,全表扫描获取结果的成本很高。
您可以通过在姓氏列上定义二级索引来提高此查询的性能:
CREATE INDEX SingersByLastName ON Singers (LastName);
由于二级索引 SingersByLastName
包含已编入索引的表列 LastName
和主键列 SingerId
,因此 Spanner 可以从小得多的索引表中提取所有数据,而无需扫描整个 Singers
表。
在这种情况下,Spanner 会在执行查询时自动使用二级索引 SingersByLastName
(自数据库创建以来已经过去三天;请参阅关于新数据库的说明)。但最佳做法是,在 FROM
子句中指定一条索引指令,以明确指示 Spanner 使用该索引:
GoogleSQL
SELECT s.SingerId
FROM Singers@{FORCE_INDEX=SingersByLastName} AS s
WHERE s.LastName = 'Smith';
PostgreSQL
SELECT s.SingerId
FROM Singers /*@ FORCE_INDEX=SingersByLastName */ AS s
WHERE s.LastName = 'Smith';
现在,假设除了 ID 之外,您还想获取歌手的名字。即使索引中不包含 FirstName
列,您仍应像前面一样指定索引指令:
GoogleSQL
SELECT s.SingerId, s.FirstName
FROM Singers@{FORCE_INDEX=SingersByLastName} AS s
WHERE s.LastName = 'Smith';
PostgreSQL
SELECT s.SingerId, s.FirstName
FROM Singers /*@ FORCE_INDEX=SingersByLastName */ AS s
WHERE s.LastName = 'Smith';
您仍然可以通过使用索引获得性能优势,因为在执行查询计划时,Spanner 不需要执行全表扫描。相反,它会从 SingersByLastName
索引中选择满足谓词的那部分行,然后从基表 Singers
执行查询,以便仅为这部分行提取名字。
如果您希望 Spanner 根本不需要从基表中提取任何行,则可以将 FirstName
列的副本存储在索引本身中:
GoogleSQL
CREATE INDEX SingersByLastName ON Singers (LastName) STORING (FirstName);
PostgreSQL
CREATE INDEX SingersByLastName ON Singers (LastName) INCLUDE (FirstName);
像这样使用 STORING
子句(适用于 GoogleSQL 方言)或 INCLUDE
子句(适用于 PostgreSQL 方言)会占用额外的存储空间,但具有以下优势:
- 如果 SQL 查询使用索引并选择存储在
STORING
或INCLUDE
子句中的列,则不需要与基表进行额外联接。 - 使用索引的读取调用可以读取存储在
STORING
或INCLUDE
子句中的列。
前面的示例说明了当可以使用二级索引快速识别查询的 WHERE
子句所选择的行时,二级索引如何加快查询的运行速度。
此外,对于返回有序结果的某些查询,二级索引也有助于提高性能。例如,假设您想要按发布日期的升序和专辑标题的降序提取所有专辑标题及其发布日期。您可以编写如下 SQL 查询:
SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums AS a
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;
如果没有二级索引,则此查询可能需要在执行计划中执行一个开销很大的排序步骤。您可以通过定义此二级索引来加快查询的执行速度:
CREATE INDEX AlbumsByReleaseDateTitleDesc on Albums (ReleaseDate, AlbumTitle DESC);
然后,重写查询以使用二级索引:
GoogleSQL
SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums@{FORCE_INDEX=AlbumsByReleaseDateTitleDesc} AS a
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;
PostgreSQL
SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums /*@ FORCE_INDEX=AlbumsByReleaseDateTitleDesc */ AS s
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;
此查询和索引定义满足以下两个条件:
- 如需移除排序步骤,请确保
ORDER BY
子句中的列列表是索引键列表的前缀。 - 为避免从基表联接以提取任何缺失的列,请确保索引涵盖查询使用的表中的所有列。
虽然二级索引可以加快常见查询的运行速度,但添加二级索引会增加提交操作的延迟时间,因为每个二级索引通常需要在每次提交中都涉及一个额外的节点。对于大多数工作负载而言,最好是使用少量二级索引。但是,您应该考虑您是否更在意读取或写入延迟,并考虑哪些操作对于您的工作负载最为关键。请对工作负载进行基准测试,以确保其性能符合预期。
如需查看二级索引的完整参考,请参阅二级索引。
优化扫描
在扫描数据时使用面向批处理的处理方法(而非较为常见的面向行的处理方法),某些 Spanner 查询可能会受益。批量处理扫描是一次性处理大量数据的更高效方法,并且可让查询实现更低的 CPU 利用率和延迟。
Spanner 扫描操作始终在面向行的模式下开始执行。在此期间,Spanner 会收集多个运行时指标。然后,Spanner 会根据这些指标的结果应用一组启发法,以确定最佳扫描模式。在适当情况下,Spanner 会切换到面向批处理的处理模式,以帮助提高扫描吞吐量和性能。
常见使用场景
具有以下特征的查询通常受益于使用面向批处理的查询:
- 对不经常更新的数据进行大规模扫描。
- 使用谓词对固定宽度的列进行扫描。
- 跳转次数较大的扫描。(搜寻使用索引来检索记录。)
性能没有提升的用例
并非所有查询都从面向批处理的处理中受益。以下查询类型在面向行的扫描处理中表现更好:
- 点查找查询:仅提取一行的查询。
- 小型扫描查询:仅扫描几行的表扫描(除非这些扫描具有较大的跳转计数)。
- 使用
LIMIT
的查询。 - 读取高流失率数据的查询:频繁更新读取的数据量超过约 10% 的查询。
- 行包含大型值的查询:大型值行是指单个列中包含大于 32,000 个字节(预压缩)的值的查询。
如何检查查询使用的扫描方法
如需检查您的查询是使用面向批处理的处理方式、面向行的处理方式,还是会自动在两种扫描方法之间切换,请执行下列操作:
转到 Google Cloud 控制台中的 Spanner 实例页面。
点击要调查的查询所属的实例的名称。
在“数据库”表下,点击要调查的查询所在的数据库。
在导航菜单中,点击 Spanner Studio。
点击
新的 SQL 编辑器标签页或 新标签页,打开一个新标签页。在查询编辑器出现时,编写查询。
点击运行。
Spanner 运行查询并显示结果。
点击查询编辑器下方的说明标签页。
Spanner 显示了查询计划执行计划可视化工具。图表上的每张卡片代表一个迭代器。
点击表扫描迭代器卡片以打开信息面板。
信息面板会显示所选扫描的相关上下文信息。扫描方法会显示在此卡片上。自动表示由 Spanner 决定扫描方法。其他可能的值包括 Vectorized(用于面向批处理)和 Scalar(用于面向行的处理)。
如何强制执行查询使用的扫描方法
为了优化查询性能,Spanner 会为您的查询选择最佳扫描方法。我们建议您使用此默认扫描方法。不过,在某些情况下,您可能需要强制执行特定类型的扫描方法。
如何强制执行面向批量的扫描
您可以在表级和语句级强制执行面向批量的扫描。
如需在表级层强制执行面向批量的扫描方法,请在查询中使用表提示:
GoogleSQL
SELECT ...
FROM (t1@{SCAN_METHOD=BATCH} JOIN t2 ON ...)
WHERE ...
PostgreSQL
SELECT ...
FROM (t1/*@ scan_method=batch */ JOIN t2 on ...)
WHERE ...
如需在语句级别强制执行面向批量的扫描方法,请在查询中使用语句提示:
GoogleSQL
@{SCAN_METHOD=BATCH}
SELECT ...
FROM ...
WHERE ...
PostgreSQL
/*@ scan_method=batch */
SELECT ...
FROM ...
WHERE ...
如何停用自动扫描并强制执行面向行的扫描
虽然我们不建议停用 Spanner 设置的自动扫描方法,但您可能会决定将其停用,并使用面向行的扫描方法来排查问题,例如诊断延迟时间。
如需停用自动扫描方法并在表级层强制执行行处理,请在查询中使用表提示:
GoogleSQL
SELECT ...
FROM (t1@{SCAN_METHOD=ROW} JOIN t2 ON ...)
WHERE ...
PostgreSQL
SELECT ...
FROM (t1/*@ scan_method=row */ JOIN t2 on ...)
WHERE ...
如需停用自动扫描方法并在语句级别强制执行行处理,请在查询中使用语句提示:
GoogleSQL
@{SCAN_METHOD=ROW}
SELECT ...
FROM ...
WHERE ...
PostgreSQL
/*@ scan_method=row */
SELECT ...
FROM ...
WHERE ...
优化范围键查找
SQL 查询的一个常见用途是根据已知键的列表从 Spanner 中读取多行。
以下最佳实践有助于您在通过一系列键提取数据时编写高效的查询:
如果键列表稀疏且不相邻,请使用查询参数和
UNNEST
来构造查询。例如,如果您的键列表是
{1, 5, 1000}
,请编写类似下面的查询:GoogleSQL
SELECT * FROM Table AS t WHERE t.Key IN UNNEST (@KeyList)
PostgreSQL
SELECT * FROM Table AS t WHERE t.Key IN UNNEST ($1)
备注:
如果键列表相邻且在一个范围内,请在
WHERE
子句中指定键范围的下限和上限。例如,如果您的键列表是
{1,2,3,4,5}
,请按如下方式构造查询:GoogleSQL
SELECT * FROM Table AS t WHERE t.Key BETWEEN @min AND @max
PostgreSQL
SELECT * FROM Table AS t WHERE t.Key BETWEEN $1 AND $2
只有当键范围内的键相邻时,此查询才会更高效。换句话说,如果您的键列表是
{1, 5, 1000}
,请勿像上述查询中那样指定下限和上限,因为生成的查询会扫描介于 1 到 1000 之间的每个值。
优化联接
联接操作成本高昂,因为它们会显著增加查询需要扫描的行数,从而导致查询速度变慢。除了您在其他关系型数据库中惯用的优化联接查询的方法之外,在使用 Spanner SQL 时,您还可以采用以下最佳做法,实现更高效的联接:
如果可能,请通过主键联接交错表中的数据。例如:
SELECT s.FirstName, a.ReleaseDate FROM Singers AS s JOIN Albums AS a ON s.SingerId = a.SingerId;
交错表
Albums
中的行一定会以物理方式与Singers
中的父行一起存储在同一个分片中,如架构和数据模型中所述。因此,可在本地完成联接,而无需通过网络发送大量数据。如果要强制联接顺序,请使用联接指令。例如:
GoogleSQL
SELECT * FROM Singers AS s JOIN@{FORCE_JOIN_ORDER=TRUE} Albums AS a ON s.SingerId = a.Singerid WHERE s.LastName LIKE '%x%' AND a.AlbumTitle LIKE '%love%';
PostgreSQL
SELECT * FROM Singers AS s JOIN/*@ FORCE_JOIN_ORDER=TRUE */ Albums AS a ON s.SingerId = a.Singerid WHERE s.LastName LIKE '%x%' AND a.AlbumTitle LIKE '%love%';
联接指令
FORCE_JOIN_ORDER
指示 Spanner 使用查询中指定的联接顺序(即Singers JOIN Albums
,而不是Albums JOIN Singers
)。无论 Spanner 选择何种顺序,返回的结果都相同。但是,如果您在查询计划中发现 Spanner 更改了联接顺序并导致了不良后果(例如较大的中间结果数)或错失了查找行的机会,则可能需要使用此联接指令。使用联接指令选择一种联接实现。当您使用 SQL 查询多个表时,Spanner 会自动使用可能提高查询效率的联接方法。不过,Google 建议您使用不同的联接算法进行测试。选择正确的联接算法可以缩短延迟时间和/或降低内存消耗。此查询演示了以下语法:使用 JOIN 指令和
JOIN_METHOD
提示选择HASH JOIN
:GoogleSQL
SELECT * FROM Singers s JOIN@{JOIN_METHOD=HASH_JOIN} Albums AS a ON a.SingerId = a.SingerId
PostgreSQL
SELECT * FROM Singers s JOIN/*@ JOIN_METHOD=HASH_JOIN */ Albums AS a ON a.SingerId = a.SingerId
如果您使用的是
HASH JOIN
或APPLY JOIN
,并且JOIN
的一侧具有高度选择性的WHERE
子句,请将生成行数最少的表作为第一个表放入联接的FROM
子句中。此结构有所帮助,因为目前在HASH JOIN
中,Spanner 始终选择左侧表作为 build,选择右侧表作为探测参数。同样,对于APPLY JOIN
,Spanner 会选择左侧表作为外侧,选择右侧表作为内侧。如需详细了解这些联接类型,请参阅哈希联接和应用联接。对于对您的工作负载至关重要的查询,请在 SQL 语句中指定性能最高的联接方法和联接顺序,以获得更加一致的性能。
在读写事务中避免大量读取
在提交调用之前,读写事务允许一系列(零个或多个)读取或 SQL 查询,并且可以包含一组变更。为了保持数据的一致性,Spanner 会在从表和索引中读取和写入行时获取锁。如需详细了解锁定,请参阅读取和写入的生命周期。
由于 Spanner 中锁定的工作方式,执行读取大量行(例如 SELECT * FROM Singers
)的读取或 SQL 查询意味着,在您的事务被提交或中止之前,没有其他事务可以写入您已读取的行。
此外,由于您的事务正在处理大量行,因此它所花的时间可能比读取小得多行范围的事务(例如 SELECT LastName FROM Singers WHERE SingerId = 7
)所花的时间,这进一步加剧了问题并降低了系统吞吐量。
因此,除非您愿意接受较低的写入吞吐量,否则请尽量避免在事务中执行大量读取(例如,全表扫描或大规模联接操作)。
在某些情况下,以下模式可以产生更好的结果:
- 在只读事务中进行大量读取。只读事务不使用锁,因此可实现更高的总吞吐量。
- 可选:对刚刚读取的数据执行所需的任何处理。
- 启动一个读写事务。
- 自您在第 1 步中执行只读事务以来,验证关键行没有更改值。
- 如果行已更改,请回滚您的事务并从第 1 步重新开始。
- 如果一切正常,则提交您的变更。
避免在读写事务中执行大量读取的一种方法是查看查询生成的执行计划。
使用 ORDER BY 来确保 SQL 结果的排序
如果您希望 SELECT
查询结果按特定顺序排列,请明确添加 ORDER BY
子句。例如,如果要按主键顺序列出所有歌手,请使用以下查询:
SELECT * FROM Singers
ORDER BY SingerId;
仅当查询中存在 ORDER BY
子句时,Spanner 才能保证结果的排序。换句话说,请考虑不含 ORDER
BY
的以下查询:
SELECT * FROM Singers;
Spanner 不保证此查询的结果将按主键顺序排列。此外,结果的排序可能会随时更改,并且无法保证在各个调用之间保持一致。如果查询具有 ORDER BY
子句,并且 Spanner 使用的索引提供了所需顺序,则 Spanner 不会明确对数据进行排序。因此,您不必担心添加此子句对性能的影响。您可以通过查看查询计划来检查执行中是否包含显式排序操作。
使用 STARTS_WITH 而不是 LIKE
由于 Spanner 在执行之前不会评估参数化 LIKE
模式,因此 Spanner 必须读取所有行并根据 LIKE
表达式对其进行评估,以过滤掉不匹配的行。
如果 LIKE
模式采用 foo%
形式(例如,以固定字符串开头,以一个通配符百分比结尾),并且该列已编入索引,请使用 STARTS_WITH
而不是 LIKE
。通过此选项,Spanner 可以更有效地优化查询执行计划。
不推荐:
GoogleSQL
SELECT a.AlbumTitle FROM Albums a WHERE a.AlbumTitle LIKE @like_clause;
PostgreSQL
SELECT a.AlbumTitle FROM Albums a WHERE a.AlbumTitle LIKE $1;
建议:
GoogleSQL
SELECT a.AlbumTitle FROM Albums a WHERE STARTS_WITH(a.AlbumTitle, @prefix);
PostgreSQL
SELECT a.AlbumTitle FROM Albums a WHERE STARTS_WITH(a.AlbumTitle, $2);
使用提交时间戳
如果您的应用需要查询在特定时间之后写入的数据,请将提交时间戳列添加到相关表中。提交时间戳可实现 Spanner 优化,从而减少以下查询的 I/O:如果查询的 WHERE
子句将结果限制为比特定时间最近写入的行。
详细了解 GoogleSQL 方言数据库或 PostgreSQL 方言数据库的此优化。