SQL 最佳做法

如查询执行计划中所述，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;

如需查看完整的 SQL 参考文档，请参阅语句语法、函数和运算符以及词汇结构和语法。

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 Studio（在 Google Cloud 控制台中以前称为查询）支持在单个编辑器中执行 SQL、DML 和 DDL 操作。如需了解详情，请参阅使用 Google Cloud 控制台管理您的数据

在 Spanner 中，您能够使用指定您想要检索的数据的声明式 SQL 语句来查询数据库。如果您想了解 Spanner 如何获取结果，请检查查询的执行计划。查询执行计划显示与查询的每个步骤相关的计算开销。借助这些开销信息，您可以调试查询性能问题并优化查询。如需了解详情，请参阅查询执行计划。

您可以通过 Google Cloud 控制台或客户端库检索查询执行计划。

如需使用 Google Cloud 控制台获取特定查询的查询执行计划，请按以下步骤操作：

1. 打开 Spanner 实例页面。

   前往 Spanner 实例

2. 选择要查询的 Spanner 实例和数据库的名称。

3. 点击左侧导航面板中的 Spanner Studio。

4. 在文本字段中键入查询，然后点击运行查询。

5. 点击说明。
   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（只要距离数据库创建后经过了 3 天）；请参阅有关新数据库的说明）。但最佳做法是，在 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 字节（压缩前）的行。

检查查询使用的扫描方法

如需检查查询是使用面向批处理的处理方法、面向行的处理方法，还是在两种扫描方法之间自动切换，请执行以下操作：

1. 前往Google Cloud 控制台中的 Spanner 实例页面。

   转到“实例”页面

2. 点击包含要调查的查询的实例的名称。

3. 在“数据库”表下，点击包含要调查的查询的数据库。

4. 在导航菜单中，点击 Spanner Studio。

5. 点击 新的 SQL 编辑器标签页或 新标签页以打开新标签页。

6. 在查询编辑器出现时，编写查询。

7. 点击运行。

   Spanner 会运行查询并显示结果。

8. 点击查询编辑器下方的说明标签页。

   Spanner 会显示查询执行计划可视化工具。图表上的每个卡片都表示一个迭代器。

9. 点击表扫描迭代器卡片，打开信息面板。

   信息面板会显示所选扫描的上下文信息。此卡片上显示了扫描方法。 自动表示 Spanner 会确定扫描方法。其他可能的值包括：批处理（表示批处理）和 行（表示行处理）。

   

强制执行查询使用的扫描方法

为了优化查询性能，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 ...

优化查询执行

除了优化扫描之外，您还可以通过在语句级别强制执行相应的执行方法来优化查询执行。这仅适用于某些运算符，并且与扫描运算符专用的扫描方法无关。

默认情况下，大多数运算符以面向行的方法执行，即一次处理一行数据。向量化运算符以面向批处理的方法执行，来帮助提高执行吞吐量和性能。这些运算符一次处理一个数据块。当运算符需要处理许多行时，面向批处理的执行方法通常更高效。

执行方法与扫描方法

查询执行方法独立于查询扫描方法。您可以在查询提示中设置这两种方法中的一种、两种或都不设置。

查询执行方法是指查询运算符处理中间结果的方式以及运算符相互之间的交互方式，而扫描方法是指扫描运算符与 Spanner 的存储层之间的交互方式。

强制执行查询使用的执行方法

为了优化查询性能，Spanner 会根据各种启发法为您的查询选择最佳执行方法。我们建议您使用此默认执行方法。不过在某些场景中，您可能需要强制执行特定类型的执行方法。

您可以在语句级别强制执行您的执行方法。EXECUTION_METHOD 是查询提示，而不是指令。最终，查询优化器会决定针对每个运算符使用哪种方法。

如需在语句级别强制执行批处理执行方法，请在查询中使用语句提示：

GoogleSQL

  @{EXECUTION_METHOD=BATCH}
  SELECT ...
  FROM ...
  WHERE ...

PostgreSQL

  /*@ execution_method=batch */
  SELECT ...
  FROM ...
  WHERE ...

虽然我们不建议停用 Spanner 设置的自动执行方法，但您可能会决定停用该方法并使用面向行的执行方法以进行问题排查（例如诊断延迟时间）。

如需停用自动执行方法并在语句级强制执行面向行的执行方法，请在查询中使用语句提示：

GoogleSQL

  @{EXECUTION_METHOD=ROW}
  SELECT ...
  FROM ...
  WHERE ...

PostgreSQL

  /*@ execution_method=row */
  SELECT ...
  FROM ...
  WHERE ...

检查已启用哪种执行方法

并非所有 Spanner 运算符都支持面向批处理和面向行的执行方法。对于每个运算符，查询执行计划可视化工具都会在迭代器卡片中显示执行方法。如果执行方法是批处理，则会显示批处理。如果是行处理，则会显示行。

如果查询中的运算符使用不同的执行方法来执行，则运算符之间会出现执行方法适配器 DataBlockToRowAdapter 和 RowToDataBlockAdapter，以显示执行方法的更改。

优化范围键查找

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)

  注意：

  • 数组 UNNEST 运算符可将输入数组展平为多行元素。

  • 查询参数（对于 GoogleSQL 为 @KeyList，对于 PostgreSQL 为 $1）可以加快查询速度，如上文的最佳实践中所述。

• 如果键列表相邻且在一个范围内，请在 WHERE 子句中指定键范围的下限和上限。

  例如，如果您的键列表是 {1,2,3,4,5}，请构建如下查询：

  GoogleSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key BETWEEN @min AND @max

  注意：此处的 @min 和 @max 是分别与值 1 和 5 绑定的查询参数。

  PostgreSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key BETWEEN $1 AND $2

  注意：此处的 $1 和 $2 是分别与值 1 和 5 绑定的查询参数。

  只有当键范围内的键相邻时，此查询才会更高效。换句话说，如果您的键列表是 {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 总是选择左侧表用于构建目的，而选择右侧表用于探测目的。同样，对于 APPLY JOIN，Spanner 选择左侧表作为外侧，选择右侧表作为内侧。如需详细了解这些联接类型，请参阅哈希联接和应用联接。

• 对于对工作负载至关重要的查询，请在 SQL 语句中指定性能最佳的联接方法和联接顺序，以实现更一致的性能。

使用时间戳谓词下推优化查询

时间戳谓词下推是 Spanner 中使用的一种查询优化技术，可对使用时间戳和采用基于存在时长的分层存储政策的数据的查询提高效率。启用此优化后，系统会在查询执行计划中尽可能早地对时间戳列执行过滤操作。这可以显著减少处理的数据量，并提高整体查询性能。

借助时间戳谓词下推，数据库引擎会分析查询并识别时间戳过滤条件。然后，它会将此过滤条件“下推”到存储层，以便仅从 SSD 读取基于时间戳的相关数据。这样可以最大限度地减少处理和传输的数据量，从而加快查询执行速度。

如需优化查询以便仅访问存储在 SSD 上的数据，必须满足以下条件：

• 查询必须启用时间戳谓词下推。如需了解详情，请参阅 GoogleSQL 语句提示和 PostgreSQL 语句提示
• 查询必须使用基于存在时长的限制，且该限制等于或小于数据溢出政策中指定的存在时长（在 CREATE LOCALITY GROUP 或 ALTER LOCALITY GROUP DDL 语句中使用 ssd_to_hdd_spill_timespan 选项进行设置）。如需了解详情，请参阅 GoogleSQL LOCALITY GROUP 语句和 PostgreSQL LOCALITY GROUP 语句。

• 查询中进行过滤的列必须是包含提交时间戳的时间戳列。如需详细了解如何创建提交时间戳列，请参阅 GoogleSQL 中的提交时间戳和 PostgreSQL 中的提交时间戳。这些列必须与时间戳列一起更新，并且位于具有基于存在时长的分层存储政策的同一存放区域组内。

  如果对于给定的行，所查询的部分列位于 SSD 上，另一部分列位于 HDD 上（由于列在不同时间更新并在不同时间老化到 HDD），那么使用提示时查询的性能可能会较差。这是因为查询必须填充来自不同存储层的数据。使用提示后，Spanner 会根据每个单元的提交时间戳在独立单元级别（行和列粒度级别）对数据进行老化处理，从而减慢查询速度。如需防止出现此问题，请务必在同一事务中定期更新使用此优化技术查询的所有列，以便所有列共享同一提交时间戳并受益于优化。

如需在语句级别启用时间戳谓词下推，请在查询中使用语句提示。例如：

GoogleSQL

  @{allow_timestamp_predicate_pushdown=TRUE}
  SELECT s.SingerInfo
  FROM Singers s
  WHERE s.ModificationTime > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 12 HOUR);

PostgreSQL

  /*@allow_timestamp_predicate_pushdown=TRUE*/
  SELECT s.SingerInfo
  FROM Singers s
  WHERE s.ModificationTime > CURRENT_TIMESTAMP - INTERVAL '12 hours';

在读写事务中避免大量读取

在提交调用之前，读写事务允许一系列（零个或多个）读取或 SQL 查询，并且可以包含一组变更。为了让数据保持一致，当在您的表和索引中读取和写入行时，Spanner 会获取锁定。如需详细了解锁定，请参阅读取和写入的生命周期。

由于 Spanner 中锁定的工作方式，执行读取大量行的读取或 SQL 查询（例如，SELECT * FROM Singers）意味着，除非您的事务被提交或中止，否则没有其他事务可以写入到您已读取的行。

此外，由于您的事务正在处理大量行，因此它所花的时间可能比读取更小范围行的事务（例如 SELECT LastName FROM Singers WHERE SingerId = 7）更长，这进一步加剧了问题并减少了系统吞吐量。

因此，除非您愿意接受写入吞吐量降低的状况，否则应该尽量避免在事务中进行大量读取（例如，全表扫描或大规模联接运算）。

在某些情况下，以下模式可以产生更好的结果：

1. 在只读事务中进行大量读取。只读事务不使用锁定，因此允许的总吞吐量更高。
2. 可选：对刚刚读取的数据执行任何所需处理。
3. 启动一个读写事务。
4. 从执行第 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;

注意：此示例假设 @like_clause 绑定到 'Love%'。

PostgreSQL

SELECT a.AlbumTitle FROM Albums a
WHERE a.AlbumTitle LIKE $1;

注意：此示例假设 $2 绑定到 'Love%'。

推荐：

GoogleSQL

SELECT a.AlbumTitle FROM Albums a
WHERE STARTS_WITH(a.AlbumTitle, @prefix);

注意：此示例假设 @prefix 绑定到 'Love'。 此查询比上一个查询更高效。如果在 Albums.AlbumTitle 上定义了索引，此查询将会以更快的速度运行。

PostgreSQL

SELECT a.AlbumTitle FROM Albums a
WHERE STARTS_WITH(a.AlbumTitle, $2);

注意：此示例假设 $1 绑定到 'Love'。 此查询比上一个查询更高效。如果在 Albums.AlbumTitle 上定义了索引，此查询将会以更快的速度运行。

使用提交时间戳

如果您的应用需要查询在特定时间之后写入的数据，请向相关表添加提交时间戳列。提交时间戳可实现一种 Spanner 优化，对于其 WHERE 子句将结果限制为在特定时间之后写入的行的查询，该优化可以减少其 I/O。

详细了解如何将此优化用于 GoogleSQL 方言数据库或 PostgreSQL 方言数据库。