让我们说下一张桌子:
CREATE TABLE test_insert_order (
id INT(11) NOT NULL AUTO_INCREMENT,
parent_id INT(11) NOT NULL,
name VARCHAR(20),
PRIMARY KEY (id)
);
带有一些数据,例如
INSERT INTO test_insert_order (parent_id, name) VALUES (1, 'a'),(1, 'b'),(1,'c'),(2,'b'),(2,'d'),(2,'a'),(3,'d'),(3,'a'),(4,'aa'),(5,'bb'),(6,'a'),(3,'a'),(1,'d'),(2,'c');
如果我们这样做
INSERT INTO test_insert_order (parent_id, name) SELECT 7, `name` FROM test_insert_order WHERE parent_id = 2 ORDER BY id;
我们可以假设新的自动生成的ID与select结果的ID顺序相同
SELECT id, 7, `name` FROM test_insert_order WHERE parent_id = 2 ORDER BY id;
因此结果下一个查询a.name将始终与b.name匹配
SET @i:=0;set @j:=0;
SELECT a.id, a.parent_id, a.name, a.order_id, b.id, b.parent_id, b.name, b.order_id FROM
(SELECT *, @j:=@j+1 as order_id FROM test_insert_order WHERE parent_id = 2 ORDER BY id) a,
(SELECT *, @i:=@i+1 as order_id FROM test_insert_order WHERE parent_id = 7 ORDER BY id) b
WHERE a.order_id = b.order_id;
我已经对并行胎面进行了一些测试,这始终是正确的。但是我在MySQL文档中找不到关于这种情况的任何信息。
更新:我猜这在某些集群解决方案中可能不是正确的,因为有一些实例具有自己的自动递增值模式,并且一个实例滞后并且查询执行在某些实例之间分配。但是我没有环境可以对此进行检查。
经过更多研究,我将回答我自己的问题。
我想在大多数情况下都是如此,但是我能够找到这种算法可能引起问题的情况。首先,在我的UPDATE中提到了有关集群解决方案的问题。其次,我可以想象是这样的情况,即表在id-auto_increment字段(最初从1000000而不是0开始)中有间隙,并且在执行插入语句时将auto_increment值手动更改为较低值。因此,这将破坏auto_increment模式。我建议在一些可以预测唯一性的有意义的字段中使用顺序。如果不存在,则与刚刚插入要使用的2个相同记录没有区别。
关于标题的问题。通常,单个MySQL实例中的单个批量插入中的auto_increment值将按增长顺序排列,但是在某些情况下,可能会因为auto_increment值更改为较低值而被中断。在群集解决方案上,它取决于群集的实现,并且很可能也是不可预测的。