Question

有人可以告诉我为什么会这样。原始问题总是复杂得多，但我创建了一个简单的测试用例来重现问题。首先你需要一个这样的表：

CREATE TABLE `test` (
  `test_a` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `test_b` int(11) DEFAULT NULL,
  PRIMARY KEY (`test_a`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

然后您需要尝试使用此查询更改表：

ALTER TABLE `test`
    CHANGE COLUMN `test_b` `new_test_b` INT(11) NOT NULL AFTER `test_a`,
    CHANGE COLUMN `test_a` `new_test_a` INT(11) NOT NULL AUTO_INCREMENT FIRST;

你得到这个结果：

Unknown column 'test_a' in 'test'

我不明白。当你单独进行每次改动时，它可以正常工作，但如果你一起做这些改动就会爆炸。

...编

在研究了一下之后，我想出了一些事情。我猜测也许编译器（或预处理器或其他东西）正在以相反的顺序评估逗号分隔的alter语句，通过在获得test_b之前更改test_a列名（这将使＆＃39; AFTER { {1}}＆＃39;部分没有意义..这在测试中证明是错误的，因为如果你颠倒了这样的陈述的顺序：

test_a

你最终会得到相同的结果。

接下来我假设某些类型的操作在这样的语句中具有优先权。我假设所有CHANGE COLUMN操作必须在任何列排序操作之前进行，例如＆＃39; AFTER ALTER TABLE `test CHANGE COLUMN `test_a` `new_test_a` INT(11) NOT NULL AUTO_INCREMENT FIRST, CHANGE COLUMN `test_b` `new_test_b` INT(11) NOT NULL AFTER `test_a`;＆＃39;如果是这种情况，那么在订购操作中引用新列名称是有意义的，如下所示：

test_a

这很有用。所以这一定是答案。我猜我的问题现在已经发展到各种类型的操作的优先顺序。

注意，对不起，我不打算将任何当前答案标记为正确，因为他们实际上没有回答问题，他们只是提供了做同样事情的替代方法（或陈述显而易见的事情）。

Answer 1

你可以这样做：

ALTER TABLE `test`
    CHANGE COLUMN `test_b` `new_test_b` INT(11) NOT NULL AFTER `test_a`;
ALTER TABLE `test`
    CHANGE COLUMN `test_a` `new_test_a` INT(11) NOT NULL AUTO_INCREMENT FIRST;

SQL更改其他列

1 个答案: