INSERT RETURNING 是否保证以“正确”的方式返回内容？命令？

发布于 2024-10-26 16:17:49 字数 389 浏览 6 评论 0 原文

示例：

create table foo(
    id serial, 
    txt text
);

insert into foo(txt) values ('a'),('b'),('c') returning id;

 id 
----
  1
  2
  3
(3 rows)

似乎返回值中的第一个id将始终是的id >'a'，第二个 'b' 等等，但是这是 insert into 的定义行为，还是可能会失败的巧合在奇怪的情况下？

原文

Example:

create table foo(
    id serial, 
    txt text
);

insert into foo(txt) values ('a'),('b'),('c') returning id;

Returns:

 id 
----
  1
  2
  3
(3 rows)

It seems that the first id in the return value will always be the id for 'a', the second for 'b' and so on, but is this defined behaviour of insert into, or is it a coincidence that may fail under odd circumstances?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

小霸王臭丫头 2024-11-02 16:17:56

免责声明：答案参考MariaDB 10.5+

与 PostgreSQL 一样，RETURNING 的顺序没有详细记录，所以我运行了一个原始测试用例其中返回的结果集肯定是连续的，并且与批量插入的值元组同步：

CREATE TABLE `returning_order_test_on_dup` (
    `ID` INT(11) NOT NULL AUTO_INCREMENT, 
    `VAL` INT(11) NOT NULL,
    PRIMARY KEY (`ID`), 
    UNIQUE INDEX `VAL` (`VAL`)
);

以下查询生成用于填充测试表的批量插入查询。两个查询均生成 25k 个插入值，第二个查询会偏移数千个值，以确保 ON DUPLICATE KEY UPDATE 正常工作：

SELECT CONCAT('INSERT INTO returning_order_test_on_dup (VAL) VALUES ', GROUP_CONCAT('(', seq, ')'), ' ON DUPLICATE KEY UPDATE VAL = VALUES(VAL) RETURNING *;')
FROM seq_1_to_25000;

SELECT CONCAT('INSERT INTO returning_order_test_on_dup (VAL) VALUES ', GROUP_CONCAT('(', seq, ')'), ' ON DUPLICATE KEY UPDATE VAL = VALUES(VAL) RETURNING *;')
FROM seq_20000_to_45000;

注意：seq_ *_to_* 是一个内置序列生成器

为了“安全”，我查看了 INSERT ... RETURNING 实现的测试（PR #1384）并浏览了实现，但找不到任何值元组和 RETURNING 行被期望能够发散。

使用 MariaDB 10.6 进行测试

Disclaimer: Answer refers to MariaDB 10.5+

As with PostgreSQL, the order of RETURNING is not documented in detail, so I ran a primitive test case where the returned result sets were definitely sequential and in sync with the value tuples of the bulk insert:

CREATE TABLE `returning_order_test_on_dup` (
    `ID` INT(11) NOT NULL AUTO_INCREMENT, 
    `VAL` INT(11) NOT NULL,
    PRIMARY KEY (`ID`), 
    UNIQUE INDEX `VAL` (`VAL`)
);

The following queries generate the bulk insert queries used to populate the test table. Both queries generate 25k insert values each, with the second one being offset by a few thousands to make sure that ON DUPLICATE KEY UPDATE does work properly:

SELECT CONCAT('INSERT INTO returning_order_test_on_dup (VAL) VALUES ', GROUP_CONCAT('(', seq, ')'), ' ON DUPLICATE KEY UPDATE VAL = VALUES(VAL) RETURNING *;')
FROM seq_1_to_25000;

SELECT CONCAT('INSERT INTO returning_order_test_on_dup (VAL) VALUES ', GROUP_CONCAT('(', seq, ')'), ' ON DUPLICATE KEY UPDATE VAL = VALUES(VAL) RETURNING *;')
FROM seq_20000_to_45000;

Note: seq_*_to_* is a builtin sequence generator

To be "safe", I looked at the tests of the INSERT ... RETURNING implementation (PR #1384) and glanced over the implementation, and couldn't find a hint anywhere that value tuples and the RETURNING rows are exoected to be able to diverge.

Tested with MariaDB 10.6

回复收藏 0 原文

吹泡泡o 2024-11-02 16:17:55

虽然文档并不完全清楚，但它确实指出：

如果 INSERT 命令包含 RETURNING 子句，则结果将类似于包含 RETURNING 列表中定义的列和值的 SELECT 语句，并根据该命令插入的行进行计算。

现在“类似于”并不是铁定的保证，我已经提出这个问题是为了在邮件列表上进行讨论 ...但实际上，PostgreSQL 不会弄乱 RETURNING 中值的顺序。即使我们想要优化，我们也不太可能做到这一点，因为太多的应用程序依赖于它的排序与输入相同。

所以...对于 INSERT INTO ... VALUES (...), (...), ... RETURNING ... 和对于 INSERT INTO ... SELECT .. . ORDER BY ... RETURNING ... 应该可以安全地假设结果关系与输入的顺序相同。

回复收藏 0 原文

洋洋洒洒 2024-11-02 16:17:55

我在文档中没有看到任何保证 RETURNING 订单的内容 所以我认为你不能依赖它。可能性是 RETURNING 订单将与 VALUES 订单匹配，但我没有看到任何关于 VALUES 将以什么顺序插入的保证; VALUES 几乎肯定会按从左到右的顺序插入，但同样，没有记录在案的保证。

此外，关系模型是基于设置的，因此排序是用户应用的而不是关系的固有属性。一般来说，如果无法显式指定排序，则不存在隐含的排序。

执行摘要：您看到的顺序可能总是会发生，但不能保证，所以不要依赖它。