《FAQ系列|數據導入主鍵沖突問題》要點：
本文介紹了FAQ系列|數據導入主鍵沖突問題，希望對您有用。如果有疑問，可以聯系我們。

導讀：用LOAD DATA導入數據卻一直提示主鍵沖突問題解決案例.

一、問題描述

有位學生遇到數據導入時一直提示1022主鍵沖突問題,而導入的數據明明完全沒有任何沖突,百思不得其解,請我幫忙協查.

下面是關于該問題現象描述：

1、表結構DDL

CREATE TABLE `wcp` (

? `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

? `txcode` char(4) NOT NULL,

? `notice_from` enum('page','server') ,

? `message` varchar(600) NOT NULL ,

? `signature` varchar(260) NOT NULL ,

? `payment_no` char(30) NOT NULL ,

? `notice_time` int(10) unsigned NOT NULL COMMENT ,

? `dealt_ok` tinyint(1) NOT NULL DEFAULT '0' COMMENT,

? PRIMARY KEY (`id`)

) ENGINE=ARCHIVE AUTO_INCREMENT=117 DEFAULT CHARSET=utf8;

欲導入的數據有116條,可以非常肯定的是,主鍵值都是順序增長的,完全沒有沖突,所以感覺非常奇怪.

二、原因分析

細心的同學,從上面我貼的表DDL或許能感覺出什么不對勁的味道(嗯,有點像狗狗嗅覺靈敏的意思,哈哈)

經我這么一提醒,再認真看一下,是不是真的發現了什么?嗯,很棒,答對了(從我女兒愛看的米奇妙妙屋里學到的語氣詞,嘿),該表的引擎是ARCHIVE,而不是我們常用的InnoDB或MyISAM,會不會和這個有關系呢?

ARCHIVE幾乎沒怎么被用過,非常冷門,它有什么特點呢.翻翻手冊便知：

The ARCHIVE storage engine is used for storing large amounts of data without indexes in a very small footprint.

The ARCHIVE engine supports INSERT and SELECT, but not DELETE, REPLACE, or UPDATE. It does support ORDER BY operations, BLOB columns, and basically all but spatial data types (see Section 11.17.4.1, “MySQL Spatial Data Types”). The ARCHIVE engine uses row-level locking.

The ARCHIVE engine supports the AUTO_INCREMENT column attribute. The AUTO_INCREMENT column can have either a unique or nonunique index. Attempting to create an index on any other column results in an error. The ARCHIVE engine also supports the AUTO_INCREMENT table option in CREATE TABLE and ALTER TABLE statements to specify the initial sequence value for a new table or reset the sequence value for an existing table, respectively.

可以看到,ARCHIVE引擎和我們平時用的InnoDB、MyISAM區別還是很大的.它不支持DELETE、REPLACE、UPDATE等操作命令,只支持INSERT、SELECT、LOAD DATA等.ARCHIVE也支持自增列屬性,但也必須是普通索引、唯一索引或主鍵索引(這個和其他引擎基本一致).

接下來我們嘗試解決數據導入主鍵沖突的問題.

三、問題解決

在這個例子中,想要最終能導入數據的話,有幾個方法：

1. 刪除主鍵定義,或者刪除主鍵的自增屬性；
2. 修改id列的主鍵索引為唯一索引或者普通索引；
3. 調整表DDL定義時指定的AUTO_INCREMENT值為0或1；
4. 修改表引擎為InnoDB或MyISAM；
5. 第3個解決方案也是我自己幾次反復測試才發現的,手冊中也未提及,比較奇葩,這也是這次的案例令人最為不解的地方.

四、其他建議

我在很多場合強調過,InnoDB引擎已可適用95%以上的業務場景,完全沒必要再使用其他引擎了,這次的奇葩案例也是一開始沒注意到用ARCHIVE引擎而走了些彎路.

不聽老葉言,吃虧在眼前,這話我看在理,嘿嘿~

文/葉金榮

原文出處——MySQL中文網微信公眾號

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4517.html