خطای Duplicate entry 1062 هنگام درون‌ریزی دیتابیس؛ چطور اطلاعات را از دست ندهیم؟

در phpMyAdmin فایل پشتیبان دیتابیس را وارد می‌کنید، اما وسط کار با خطایی مثل 1062 Duplicate entry ... for key PRIMARY روبه‌رو می‌شوید. معنی ساده آن این است که یک مقدار با قانونی که باید یکتا باشد تداخل کرده است. این اتفاق می‌تواند وقتی پیش بیاید که مقصد از قبل داده دارد، واردسازی قبلی نیمه‌تمام مانده یا خود داده ورودی با ساختار مقصد سازگار نیست.

خطا دلیل کافی برای حذف جدول، نادیده گرفتن همه ردیف‌های تکراری یا اجرای دوباره فایل روی دیتابیس سایت فعال نیست. بخشی از فایل ممکن است پیش از خطا وارد شده باشد و حذف عجولانه می‌تواند سفارش‌ها یا اطلاعات تازه را از بین ببرد. در این راهنما ابتدا مقصد و کلید را پیدا می‌کنیم و سپس بازیابی را روی دیتابیس آزمایشی بررسی می‌کنیم.

فرض کنید خطا می‌گوید یک مقدار برای کلید PRIMARY تکراری است. کلید اصلی معمولاً برای شناسایی یکتای هر ردیف استفاده می‌شود. اگر کلید دیگری با نام متفاوت در پیام دیده می‌شود، ممکن است یک شاخص UNIQUE روی یک یا چند ستون باشد. مرجع خطاهای MySQL کد ۱۰۶۲ را به ورود داده تکراری نسبت می‌دهد.

نام جدول، نام کلید، مقدار اعلام‌شده، نام دیتابیس انتخاب‌شده و زمان را ثبت کنید. مقدار خطا ممکن است آدرس ایمیل یا اطلاعات مشتری باشد؛ هنگام ارسال تصویر برای پشتیبانی آن را با حفظ امکان تشخیص مخفی کنید. خطای 1064 درباره نحو SQL یا خطای Unknown collation علت متفاوتی دارد؛ شماره و متن دقیق را با هم بخوانید.

در phpMyAdmin به نام دیتابیسی که در ستون سمت چپ انتخاب شده نگاه کنید. آیا همان دیتابیس سایت در حال فروش است یا دیتابیس جداگانه‌ای برای آزمایش؟ اگر مقصد فعال است، تغییر دیگری انجام ندهید تا وضعیت آن روشن شود. واردسازی SQL می‌تواند دستورهایی برای ساخت، تغییر یا حتی حذف جدول داشته باشد؛ فایل بکاپ را فقط از منبع مطمئن استفاده کنید و محتوایش را پیش از اجرا بشناسید.

اگر یک بار Import با خطا متوقف شده، فرض نکنید هیچ تغییری رخ نداده است. بسته به فایل، ابزار، نوع جدول و نقطه توقف، ممکن است بخشی از داده یا ساختار قبلاً اعمال شده باشد. اجرای دوباره همان فایل روی همان مقصد ممکن است تداخل تازه ایجاد کند. زمان آخرین نسخه سالم و هر اطلاعات جدید پس از آن، به‌خصوص سفارش‌های فروشگاه، باید در برنامه بازیابی لحاظ شود.

اگر به بکاپ نیاز دارید، از دیتابیس فعلی خروجی جداگانه و قابل بازیابی بگیرید و پیش از دستکاری، آن را در محل امن نگه دارید. در راهنمای بازیابی بکاپ فروشگاه و سفارش‌های جدید توضیح داده‌ایم چرا بازگرداندن نسخه قدیمی به‌تنهایی داده‌های بعد از زمان بکاپ را حفظ نمی‌کند.

دیتابیس مربوط به محیط آزمایشی را در phpMyAdmin انتخاب کنید و جدول نام‌برده در خطا را باز کنید. در بخش Structure / ساختار، فهرست ستون‌ها و شاخص‌ها را ببینید. نام PRIMARY یا UNIQUE خطا را با شاخص جدول مقایسه کنید. در برخی نسخه‌ها نام شاخص و ستون‌های تشکیل‌دهنده آن در بخش Indexes پایین صفحه دیده می‌شوند.

برای مدیر آشنا با SQL، دستور زیر مشخصات شاخص‌های جدول نمونه را فقط می‌خواند. نام جدول نمونه را با نام جدول واقعی در دیتابیس آزمایشی جایگزین کنید:

ستون Key_name نام شاخص و Column_name ستون‌های آن را نشان می‌دهد. اگر یک شاخص از چند ستون ساخته شده، تکراری بودن ترکیب آن‌ها مهم است، نه الزاماً یک ستون به‌تنهایی. قواعد NULL، طول شاخص و روش مقایسه حروف نیز می‌توانند بر نتیجه اثر بگذارند؛ مستندات شاخص یکتای MySQL جزئیات را توضیح می‌دهد. نام‌ها و ساختار در MariaDB یا نسخه‌های دیگر باید با مستندات همان سرور تطبیق داده شوند.

اگر خطا مقدار مشخصی را نشان می‌دهد، در نمای Browse یا Search جدول آزمایشی همان مقدار و ستون مربوط را جست‌وجو کنید. وجود ردیف نشان می‌دهد مقصد از قبل چنین کلیدی دارد، اما به‌تنهایی روشن نمی‌کند ردیف مقصد و ردیف فایل یکسان‌اند یا کدام‌یک باید نگه داشته شود. داده‌های مالی یا مشتری را بدون بررسی مالک تغییر ندهید.

اگر هدف شما بررسی سلامت بکاپ یا مهاجرت کامل است، در کنترل‌پنل میزبانی یک دیتابیس جدید و مستقل با نام مشخص آزمایشی بسازید. یک کاربر مجاز همان دیتابیس را طبق راهنمای میزبان به آن متصل کنید و نام دقیق دیتابیس و پیشوند احتمالی حساب را یادداشت کنید. پایگاه فعال را حذف یا تخلیه نکنید.

سپس در phpMyAdmin دیتابیس تازه را انتخاب کنید و قبل از Import مطمئن شوید همان مقصد انتخاب شده است. پیش از اجرا، فایل SQL را از نظر وجود دستورهایی مثل انتخاب دیتابیس یا تغییر ساختار بررسی کنید؛ بعضی فایل‌ها ممکن است نام دیتابیس دیگری را مشخص کنند. اگر محتوای فایل را نمی‌شناسید یا مطمئن نیستید دستوراتش به چه مقصدی اثر می‌گذارد، از سازنده بکاپ یا مدیر پایگاه داده بخواهید آن را بررسی کند.

فایل را در مقصد آزمایشی طبق راهنمای درون‌ریزی و برون‌ریزی phpMyAdmin وارد کنید و پیام کامل پایان یا خطا را ثبت کنید. اگر محدودیت اندازه یا زمان موجب قطع واردسازی شد، روش مناسب همان میزبان را انتخاب کنید؛ تلاش مکرر روی دیتابیس نیمه‌پر، نتیجه آزمایش تمیزی نمی‌دهد.

| نتیجه | معنی احتمالی و اقدام بعدی | | --- | --- | | فایل در دیتابیس خالی موفق است اما در مقصد قبلی خطای ۱۰۶۲ داشت | داده یا ساختار مقصد قبلی با فایل تداخل داشته است. مشخص کنید هدف جایگزینی کامل، ادغام یا تکمیل واردسازی بوده و برای آن روش جداگانه طراحی کنید. | | فایل در دیتابیس خالی هم همان خطا را می‌دهد | ممکن است خود فایل، ترتیب دستورات، داده‌های تکراری یا تفاوت ساختار و نسخه مسئله داشته باشد. نام جدول، کلید و دستور محل خطا را با سازنده بکاپ بررسی کنید. | | ابتدا فایل دیگری وارد شده و سپس فایل دوم خطا می‌دهد | ممکن است هر دو داده یا شناسه یکسان داشته باشند. برای ادغام، نگاشت و قواعد حفظ هر دو مجموعه لازم است؛ صرف رد کردن ردیف‌ها کافی نیست. | | پیام از تکرار نام جدول است نه Duplicate entry 1062 | مشکل می‌تواند وجود ساختار جدول باشد و باید پیام دقیق آن دنبال شود؛ این دو خطا یکی نیستند. |

برای یک فایل کامل، موفق بودن پیغام Import هم تمام ماجرا نیست. جدول‌های مهم، شمار تقریبی ردیف‌ها، چند رکورد نمونه و امکان کار برنامه را در محیط آزمایشی با منبع مقایسه کنید. شمار برابر به‌تنهایی یکسان بودن همه محتوا را تضمین نمی‌کند.

گزینه‌هایی وجود دارند که در برخی شرایط ردیف تکراری را نادیده می‌گیرند یا ردیف موجود را جایگزین می‌کنند. این کار ممکن است سفارش، کاربر یا رابطه بین داده‌ها را بی‌صدا از قلم بیندازد یا تغییر دهد. حذف شاخص یکتا نیز قوانین برنامه را ضعیف می‌کند و ممکن است در آینده خطاهای تازه بسازد. این‌ها تصمیم‌های طراحی داده‌اند، نه دکمه عمومی رفع ۱۰۶۲.

اگر قصد شما ادغام دو دیتابیس است، ابتدا مشخص کنید شناسه‌های مشترک به یک موجودیت اشاره دارند یا به دو مورد متفاوت. نسخه جداگانه هر دو منبع را نگه دارید، قواعد ادغام و نگاشت شناسه‌ها را با مالک داده طراحی کنید و ابتدا روی کپی آزمایش کنید. برای یک فروشگاه فعال، سفارش‌ها و پرداخت‌های ثبت‌شده بعد از زمان بکاپ باید جداگانه تطبیق داده شوند؛ راه‌حل یکسانی برای همه فروشگاه‌ها وجود ندارد.

اگر هدف بازیابی کامل در محیط آزمایشی بود، نتیجه را با فایل اصلی، جدول‌ها و چند عملیات واقعی برنامه مقایسه کنید. برای وردپرس، اتصال نسخه آزمایشی به دیتابیس جدا، نمایش محتوا و یک عملیات بی‌خطر را بررسی کنید؛ اطلاعات اتصال و رمز را در گزارش عمومی ننویسید. هیچ نسخه آزمایشی را بدون محدودسازی دسترسی در معرض مشتریان قرار ندهید.

انتقال نتیجه به سایت اصلی باید با برنامه مشخص برای زمان توقف، داده‌های جدید، بکاپ قابل بازگشت و هماهنگی مالک انجام شود. اگر صرفاً سلامت فایل را می‌سنجید، لازم نیست دیتابیس زنده را تغییر دهید. برای بررسی امکانات میزبانی سایت، صفحه هاست وردپرس نت‌آرام در دسترس است.