كيف تنظّف وتحسّن قاعدة بيانات ووردبريس؟ دليل عملي يدويًّا وبالإضافات

قبل أن نبدأ، لنضع حدًّا فاصلًا مهمًّا. هذا المقال يعالج تنظيف قاعدة ووردبريس من منظور مالك الموقع: مراجعات، ترانزيانت، autoload، بيانات يتيمة — أشياء تفعلها بنفسك من لوحة التحكم أو phpMyAdmin أو سطر الأوامر دون معرفة عميقة بهندسة قواعد البيانات. أمّا التحسين على مستوى المحرّك (الفهرسة Indexes، ضبط الاستعلامات البطيئة، تكوين خادم MySQL، كاش الكائنات بـRedis) فموضوع أعمق يخصّ الأداء العام لأي قاعدة، وقد أفردنا له تحسين قاعدة البيانات (الدليل العام). الفرق بإيجاز: العام = بنية تحتية وأداء استعلامات؛ وهذا = صيانة محتوى يقوم بها صاحب الموقع. الاثنان يكمّلان بعضهما، ولا يغني أحدهما عن الآخر.

لماذا تتضخّم قاعدة ووردبريس تحديدًا؟

ووردبريس لا يحفظ صفحاتك كملفات جاهزة، بل يبنيها في كل زيارة من قاعدة بيانات علائقية (MySQL أو MariaDB). كل مقال، وكل تعليق، وكل إعداد، وكل خيار إضافة — كلّه صفوف في جداول. هذا التصميم مرن للغاية، لكنه يعني أنّ القاعدة تنمو باستمرار، وأنّ جزءًا كبيرًا من هذا النموّ زائد لا قيمة له: نسخ مكرّرة، وبيانات مؤقّتة انتهت صلاحيتها، وبقايا محتوى حذفته منذ سنوات لكن أثره بقي.

المشكلة أنّ ووردبريس لا يكنس خلفه تلقائيًّا. حين تحذف مقالًا، تختفي بياناته الأساسية من wp_posts، لكن حقوله المخصّصة في wp_postmeta قد تبقى معلّقة بلا أب. حين تحذف إضافة، يبقى ما أنشأته من جداول وخيارات مبعثرًا في القاعدة. وحين تنتهي صلاحية بيانات مؤقّتة (ترانزيانت)، لا يحذفها ووردبريس استباقيًّا، بل ينتظر حتى تُطلب مرّة أخرى ليكتشف انتهاءها. النتيجة: قاعدة تتراكم فيها الطبقات الميتة كالغبار خلف الأثاث.

خطورة هذا التضخّم ليست في حجم القاعدة على القرص (بضعة ميغابايت لن تؤذيك)، بل في بندٍ واحد تحديدًا: خيارات autoload. هذه خيارات يحمّلها ووردبريس في ذاكرة كل طلب صفحة قبل أن يفعل أي شيء آخر. إذا تضخّمت هذه الخيارات إلى مئات الكيلوبايتات، فأنت تدفع ضريبة على كل زيارة لكل زائر — وهنا يظهر الأثر على السرعة وCore Web Vitals بوضوح. لهذا سنعطي autoload حصّة الأسد من الاهتمام لاحقًا.

بنية جداول ووردبريس: خريطة قبل التنظيف

قبل أن تلمس أي شيء، يجب أن تعرف ماذا تلمس. تركيب ووردبريس الافتراضي يُنشئ 12 جدولًا أساسيًّا، جميعها ببادئة wp_ (قد تكون مختلفة في تركيبك لأسباب أمنية). فهم دور كل جدول يمنعك من حذف ما تظنّه نفاية وهو في الحقيقة عصب موقعك.

القاعدة الذهبية هنا: الجداول ليست نفاية، الصفوف الزائدة داخلها هي النفاية. لن نحذف جدولًا من هذه القائمة أبدًا؛ سنحذف صفوفًا محدّدة بشروط دقيقة. الجداول الوحيدة التي قد تُحذف بالكامل هي جداول أنشأتها إضافات ثمّ حذفتها، وسنعالجها بحذر في قسم منفصل.

مصادر التضخّم في ووردبريس وكيف تنظّف كلًّا منها

الآن إلى جوهر الموضوع. لكل مصدر تضخّم طبيعةٌ مختلفة، وطريقة تنظيف مختلفة، ومستوى خطورة مختلف. الجدول التالي خريطتك الشاملة، وسنفصّل كلًّا منها بعده.

المراجعات: أكبر مصدر صامت للتضخّم

كلما ضغطت "حفظ" أو "تحديث" في محرّر ووردبريس، تُحفَظ نسخة كاملة من المقال كـ"مراجعة" (revision). أضِف إلى ذلك الحفظ التلقائي الذي يجري كل نحو 60 ثانية أثناء الكتابة. النتيجة أنّ مقالًا واحدًا حرّرته على عدّة جلسات قد يخلّف خلفه 50 مراجعة أو أكثر — كلٌّ منها نسخة كاملة تشغل مساحة في wp_posts وتخلّف حقولًا في wp_postmeta.

المراجعات مفيدة أثناء الكتابة (تتيح التراجع)، لكن الاحتفاظ بها إلى الأبد بلا حدّ إسراف. تنظيفها آمن نسبيًّا، لكن هنا مصيدة دقيقة: حذف المراجعات بعبارة DELETE بسيطة من wp_posts يترك خلفه صفوف wp_postmeta وwp_term_relationships المرتبطة بها يتيمة. لهذا الطريقة الأنظف دائمًا هي WP-CLI (لأنّه يمرّ عبر منطق ووردبريس ويحذف المرتبطات)، وإن اضطررت لـSQL فأتبِعه بتنظيف اليتيمة (سنشرحه بعد قليل).

الترانزيانت المنتهية: القمامة التي لا تُكنَس

الترانزيانت (Transients) آليّة تخزين مؤقّت في ووردبريس: تحفظ بيانات لها صلاحية زمنية (مثلًا نتيجة استعلام ثقيل لساعة). تُخزَّن في wp_options كزوجين: _transient_<name> للقيمة، و_transient_timeout_<name> لوقت الانتهاء. المشكلة الجوهرية: ووردبريس لا يحذف الترانزيانت المنتهي استباقيًّا؛ ينتظر حتى يُطلب مرّة أخرى ليكتشف انتهاءه فيحذفه. فإذا أنشأت إضافةٌ ترانزيانت لم يُطلَب ثانيةً، بقي في القاعدة إلى الأبد.

مع إضافات كثيرة نشطة، قد تتراكم آلاف الترانزيانت المنتهية. الأسوأ: بعضها قد يكون autoload=yes فيُحمَّل في كل طلب. تنظيفها من أأمن العمليات وأكثرها فائدة. القاعدة عند الحذف اليدوي: احذف زوج _transient_ و_transient_timeout_ معًا، ولا تحذف أحدهما دون الآخر. WP-CLI يفعل هذا بأمر واحد نظيف.

autoload: البند الذي يجب أن تركّز عليه فعلًا

هذا هو أهمّ قسم في المقال كلّه. عمود autoload في wp_options يحدّد أيّ الخيارات يُحمَّلها ووردبريس تلقائيًّا في بداية كل طلب صفحة، دفعةً واحدة، قبل أن يعرف ما إذا كان سيحتاجها. المنطق: توفير استعلامات منفصلة لاحقًا. لكن حين تسيء إضافةٌ الأدب وتضع خيارًا ضخمًا (مصفوفة إعدادات، سجلّ، كاش داخلي) على autoload، فأنت تُحمّل هذا الحمل على كل زائر في كل صفحة.

هنا نقطة دقّة محورية غيّرها ووردبريس حديثًا: منذ الإصدارين 6.6/6.7 لم يعد عمود autoload يخزّن yes/no فقط، بل قيمًا جديدة: on، off، auto، auto-on، auto-off. القيمتان القديمتان yes/no أصبحتا مهملتين (لا تزالان تعملان للتوافق الخلفي، لكن ووردبريس صار يكتب القيم الجديدة). إضافةً إلى ذلك، أي خيار يتجاوز حجمه 150 كيلوبايت لا يُحمَّل تلقائيًّا حتى لو طُلب ذلك. معنى هذا عمليًّا: أيّ استعلام تشخيصي قديم يبحث عن autoload='yes' فقط سيفوّت الخيارات المضبوطة على القيم الجديدة، ويعطيك صورة ناقصة. الاستعلام الصحيح اليوم يستخدم IN لا =:

SELECT option_name, LENGTH(option_value) AS size, autoload
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY size DESC
LIMIT 50;

شغّل هذا في phpMyAdmin (أو أي واجهة SQL على قاعدتك)، وستحصل على قائمة أكبر 50 خيارًا محمّلًا تلقائيًّا، مرتّبةً بالحجم تنازليًّا. اقرأ أسماءها: إن رأيت خيارًا ضخمًا يبدأ بـ_transient_ فهو ترانزيانت شارد يجب حذفه؛ وإن رأيت خيارًا باسم إضافة معروفة، ابحث في إعداداتها عن خيار "تنظيف" أو راسل مطوّرها. لمعرفة الإجمالي:

SELECT ROUND(SUM(LENGTH(option_value))/1024, 1) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');

العتبة المستهدفة: أن يبقى إجمالي حجم autoload تحت نحو 800 كيلوبايت إلى 1 ميغابايت. تجاوُز ذلك بكثير علامة على وجود خيار متضخّم يستنزف كل طلب. لا تحوّل خيارًا من autoload إلى off عشوائيًّا — قد تحتاجه إضافة نشطة على كل صفحة. الطريقة السليمة: حدّد الخيار الضخم، افهم مصدره، ثمّ عالج المصدر (حذف ترانزيانت، أو ضبط إعداد الإضافة، أو إزالة إضافة مهجورة). هذا البند وحده قد يمنحك تحسّنًا في TTFB أكبر من كل ما سواه.

ولنفهم لماذا صار الاستعلام بـIN ضروريًّا لا مجرّد احتياط، علينا أن نعرف ما الذي غيّره ووردبريس بالضبط في 6.6 وما تبعه في 6.7. قبل 6.6 كان العمود ثنائيًّا صرفًا: yes يعني حمّله في كل طلب، وno يعني لا. من 6.6 أصبح العمود يميّز بين قرارٍ يدوي صريح وقرارٍ آليّ اتّخذه ووردبريس نيابةً عنك. فـon وoff تعنيان أنّ مطوّرًا (أو أنت) فرض القيمة صراحةً عبر معامل التحميل عند add_option؛ بينما auto وauto-on وauto-off تعنيان أنّ ووردبريس هو من قرّر التحميل تلقائيًّا بناءً على حجم الخيار. هذا التمييز ليس تجميليًّا: هو يتيح لووردبريس أن يتّخذ قرارًا ذكيًّا افتراضيًّا دون أن يدوس على قرارٍ فرضه المطوّر عمدًا.

القاعدة الحاسمة التي أدخلها 6.6 هي عتبة الـ150 كيلوبايت: أيّ خيار جديد يُضاف بلا تحديد صريح لقيمة autoload، ويتجاوز حجمه هذا الحدّ، يضبطه ووردبريس تلقائيًّا على auto-off — أي يستبعده من التحميل التلقائي حمايةً لأداء كل طلب. هذا سلوك وقائيّ ممتاز، لكن انتبه: لا يُطبَّق بأثر رجعيّ. الخيارات الضخمة التي زرعتها إضافةٌ قبل 6.6 وما زالت yes ستبقى yes وتُحمَّل في كل طلب إلى أن تتدخّل يدويًّا؛ العتبة تحمي الخيارات الجديدة فقط. لهذا يظلّ التشخيص اليدوي بالاستعلام أعلاه ضروريًّا حتى على أحدث إصدار.

الآن يتّضح لماذا الاستعلام القديم WHERE autoload = 'yes' صار خطأً تشخيصيًّا حقيقيًّا لا مجرّد قصور: على موقعٍ حديث، الخيارات التي أضافها ووردبريس أو الإضافات بعد الترقية قد تحمل on أو auto أو auto-on، وكلّها تُحمَّل فعلًا في كل طلب رغم أنّها ليست yes. فلو اكتفيت بـ='yes' لرأيت جزءًا فقط من الحمل الحقيقي وظننت autoload سليمًا بينما هو منتفخ. لهذا الشرط الصحيح هو IN ('yes','on','auto','auto-on') — يجمع كل ما يُحمَّل تلقائيًّا بصرف النظر عن مصدر القرار. لاحظ أنّنا نستبعد off وauto-off عمدًا لأنّها لا تُحمَّل، فلا معنى لعدّها ضمن ميزانية autoload.

البيانات اليتيمة: بقايا بلا أب

حين تُحذف مقالات أو تعليقات، تبقى أحيانًا بياناتها الوصفية معلّقة. صفّ في wp_postmeta يشير إلى post_id لم يعد موجودًا في wp_posts هو صفّ يتيم: لا فائدة منه، ويثقل الجدول ويبطئ استعلاماته. الطريقة الأأمن لحذفه هي نمط LEFT JOIN … IS NULL، الذي يحذف فقط الصفوف التي لا أب لها فعلًا:

DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

ونفس النمط لبيانات التعليقات اليتيمة:

DELETE cm FROM wp_commentmeta cm
LEFT JOIN wp_comments c ON c.comment_ID = cm.comment_id
WHERE c.comment_ID IS NULL;

هذا النمط دقيق لأنّه لا يخمّن: يحذف حصرًا ما لا أب له في الجدول المرجعي. لكن انتبه: افحص العدد قبل الحذف دائمًا (سنشرح قاعدة SELECT قبل DELETE بعد قليل)، لأنّ بعض الإضافات تخزّن بيانات "تبدو يتيمة" لكنها تشير إلى معرّفات خاصّة بها لا إلى منشورات فعلية — وحذفها يعطبها.

لماذا LEFT JOIN … IS NULL تحديدًا لا استعلام فرعي بـNOT IN؟ الفرق في المنطق والأمان معًا. LEFT JOIN يضمّ كل صفّ في wp_postmeta إلى أبيه المحتمل في wp_posts عبر post_id = ID؛ فإن لم يجد أبًا، تأتي أعمدة wp_posts كلها NULL، وشرط WHERE p.ID IS NULL يلتقط هذه الحالة بالذات — الصفوف بلا أب فعليّ. أمّا WHERE post_id NOT IN (SELECT ID FROM wp_posts) فيبدو مكافئًا لكنه يخفي فخًّا خبيثًا: إن احتوى الاستعلام الفرعي على قيمة NULL واحدة، يعيد NOT IN نتيجة NULL للمقارنة كلها فلا يحذف شيئًا صامتًا — تظنّ أنّك نظّفت وأنت لم تفعل. LEFT JOIN أمنع من هذا الخطأ، وأسرع عادةً على الجداول الكبيرة لأنّ محسّن الاستعلام يعامله كضمّ لا كفحص عضوية متكرّر.

قبل تشغيل عبارة الحذف، حوّلها إلى عدّ لتعرف الحجم الحقيقي — بنفس البنية تمامًا، مع تبديل DELETE بـSELECT COUNT(*):

SELECT COUNT(*) FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

إن أظهر العدّ رقمًا معقولًا يتناسب مع ما حذفته من محتوى، فأنت على أرض صلبة. إن أظهر عشرات الآلاف على موقعٍ صغير، فتوقّف وافحص عيّنة بـSELECT pm.meta_key, pm.meta_value قبل أن تلمس شيئًا — قد تكون أمام إضافة تخزّن بطريقة غير معتادة. النمط نفسه ينطبق على جدول ثالث كثيرًا ما يُنسى: wp_term_relationships، حيث تبقى روابط بين مقالات محذوفة وتصنيفاتها معلّقةً بلا مقال. لكن كن أشدّ حذرًا هنا: بنية التصنيفات موزّعة على ثلاثة جداول مترابطة، وتنظيفها اليدوي أخطر من postmeta — والأأمن أن تترك ووردبريس أو WP-CLI يتولّاها لأنّها تحدّث العدّادات (count) في wp_term_taxonomy تلقائيًّا، وهو ما لن يفعله حذفك اليدوي.

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

أوامر SQL للتنظيف اليدوي: بحذر شديد

إن كنت مرتاحًا مع phpMyAdmin أو أي واجهة SQL، هذه الأوامر تنظّف مصادر التضخّم الشائعة مباشرةً. قبل تشغيل أيّ منها، اقرأ قسم الاحتياطات في نهاية المقال — النسخة الاحتياطية ليست اختيارية.

المراجعات والمسودّات التلقائية والمهملات:

-- احذف كل المراجعات (⚠️ تخلّف postmeta يتيمة — أتبِعها بتنظيف اليتيمة أو استخدم WP-CLI)
DELETE FROM wp_posts WHERE post_type = 'revision';

-- احذف المسودّات التلقائية
DELETE FROM wp_posts WHERE post_status = 'auto-draft';

-- أفرِغ المهملات (تأكّد أنّك لا تريد أيًّا منها أولًا)
DELETE FROM wp_posts WHERE post_status = 'trash';

تعليقات السبام:

DELETE FROM wp_comments WHERE comment_approved = 'spam';

قاعدتان لا تتنازل عنهما في phpMyAdmin:

الأولى، SELECT قبل DELETE: قبل أن تحذف، بدّل الكلمة DELETE بـSELECT COUNT(*) (أو SELECT * لمعاينة عيّنة) بنفس الشرط، وشاهد كم صفًّا ستمسّه. إذا توقّعت 200 مراجعة وأظهر العدّ 40 ألفًا، فثمّة خطأ في فهمك أو في شرطك — توقّف. مثال:

SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';

الثانية، لا تراجُع في phpMyAdmin: بمجرّد ضغط "تنفيذ" على عبارة DELETE، انتهى الأمر — لا زرّ "إلغاء"، لا سلّة محذوفات. الطريق الوحيد للعودة هو النسخة الاحتياطية. لهذا لا تنفّذ عبارة حذف واحدة دون نسخة جاهزة.

أمّا الترانزيانت المنتهية فحذفها بـSQL يدويًّا أصعب لأنّه يتطلّب مطابقة زوج القيمة والانتهاء ومقارنة الوقت — وهذا بالضبط ما يفعله WP-CLI بأمان في أمر واحد، فلا تعقّد حياتك.

WP-CLI: الطريقة الأنظف والأأمن

إن أتاح لك مضيفك الوصول إلى سطر الأوامر SSH، فإنّ WP-CLI هو أفضل أداة تنظيف على الإطلاق. سبب تفوّقه على SQL الخام: أوامره تمرّ عبر منطق ووردبريس نفسه، فتحذف البيانات المرتبطة تلقائيًّا (المراجعة + بياناتها الوصفية معًا) بدل أن تخلّف يتيمة. إليك الأوامر الأساسية:

# احذف كل الترانزيانت المنتهية (آمن جدًّا)
wp transient delete --expired

# احذف كل المراجعات مع بياناتها المرتبطة (لا يخلّف يتيمة)
wp post delete $(wp post list --post_type=revision --format=ids) --force

# احذف تعليقات السبام مع بياناتها
wp comment delete $(wp comment list --status=spam --format=ids) --force

# نظّف وحسّن الجداول (يستدعي OPTIMIZE TABLE داخليًّا)
wp db optimize

راية --force تعني الحذف النهائي (تخطّي المهملات) — وهي المطلوبة للمراجعات والسبام لأنّ لا معنى لإرسالها إلى سلّة. لاحظ أنّ wp post delete بلا --force سيرسل العناصر إلى المهملات فقط، وهذا عكس ما تريد هنا.

ميزة أخرى: WP-CLI قابل للأتمتة. يمكنك جدولة wp transient delete --expired أسبوعيًّا عبر cron على الخادم دون لمس القاعدة يدويًّا. لكن أبقِ الجدولة محافِظة: الترانزيانت المنتهي آمن للجدولة، أمّا حذف المهملات أو المراجعات تلقائيًّا فيُفضَّل أن يبقى بقرار يدوي واعٍ.

الجدولة عبر cron الحقيقي على الخادم (لا WP-Cron الوهميّ الذي يعمل عند الزيارات فقط) هي الطريقة النظيفة لأتمتة التنظيف الآمن. تضيف سطرًا إلى crontab بأمر crontab -e، مع الانتباه إلى تحديد المسار الكامل لـwp وللموقع لأنّ cron يعمل ببيئة صغيرة لا تعرف اختصاراتك:

# كل يوم أحد الساعة 3 فجرًا: احذف الترانزيانت المنتهية فقط
0 3 * * 0 /usr/local/bin/wp transient delete --expired --path=/var/www/html --quiet

راية --path تخبر WP-CLI بموقع تركيب ووردبريس (ضروريّة لأنّ cron لا يعمل من داخل مجلّد الموقع)، و--quiet تكتم المخرجات كي لا يرسل cron لك بريدًا في كل تشغيل. لاحظ حصر الجدولة في الترانزيانت المنتهي وحده — وهذه قاعدة لا استعراض. الترانزيانت المنتهي، بحكم تعريفه، بيانات فقدت صلاحيتها فحذفها لا يفقد شيئًا. أمّا المراجعات والمهملات فقصّة أخرى: مراجعةٌ اليوم قد تكون شبكة أمانك غدًا حين تحتاج التراجع، ومقالٌ في المهملات قد يكون حذفًا خاطئًا لم تلاحظه بعد. أتمتة حذف هذين تعني أنّ خطأً بشريًّا (حذفت المقال الخطأ) سيتحوّل إلى خسارة دائمة قبل أن تنتبه. القاعدة الذهبية للأتمتة: أتمِت ما لا رجعة في فقده، وأبقِ ما قد تندم عليه بقرار يدوي واعٍ. إن أردت جدولة أعمق (مثل حذف مراجعات أقدم من سنة)، فليكن ذلك شهريًّا لا يوميًّا، وبعد أن ضبطت WP_POST_REVISIONS أصلًا ليمنع التراكم من جذره.

أوقِف التضخّم من جذره: ثوابت wp-config.php

التنظيف علاج، لكن الوقاية أفضل. بإضافة ثوابت إلى ملف wp-config.php (فوق سطر /* That's all, stop editing! */)، تحدّ من مصادر التضخّم قبل نشوئها. ملاحظة جوهرية: هذه الثوابت لا تحذف الموجود — هي توقف النموّ المستقبلي فقط. فإذا كان لديك بالفعل 40 ألف مراجعة، فعليك حذفها يدويًّا أوّلًا، ثمّ يمنع الثابت تراكمها من جديد.

أمثلة عملية للإضافة إلى wp-config.php:

// احتفظ بآخر 5 مراجعات فقط لكل مقال
define( 'WP_POST_REVISIONS', 5 );

// باعِد الحفظ التلقائي إلى دقيقتين
define( 'AUTOSAVE_INTERVAL', 120 );

// أفرِغ المهملات تلقائيًّا بعد 7 أيام
define( 'EMPTY_TRASH_DAYS', 7 );

لاحظ الخيار WP_POST_REVISIONS = false: يعطّل المراجعات كليًّا. لا أنصح به لموقع محتوى نشط لأنّه يحرمك من التراجع، لكنه منطقي لموقع لا يُحرَّر محتواه إلا نادرًا. الوسط الذهبي عدد صغير مثل 5 أو 10 يمنحك شبكة أمان دون تضخّم. أمّا EMPTY_TRASH_DAYS = 0 فاستخدمه بحذر: يحذف كل ما ترسله إلى المهملات فورًا وبلا رجعة، وهو ما لا تريده إن كنت تحذف بسرعة أحيانًا وتندم لاحقًا.

حقيقة OPTIMIZE TABLE و"الـoverhead"

هنا تنتشر مبالغة شائعة. كثير من الأدلّة والإضافات تُظهر لك رقم "overhead" (المساحة المهدرة داخل الجداول) وتوحي بأنّ تشغيل OPTIMIZE TABLE سيحدث فرقًا كبيرًا في السرعة. الحقيقة أدقّ من ذلك، وتعتمد على محرّك التخزين:

• على MyISAM (المحرّك القديم): OPTIMIZE TABLE يزيل التجزئة فعليًّا ويستعيد المساحة المهدرة، لكنه يقفل الجدول أثناء العملية (توقّف مؤقّت للكتابة).
• على InnoDB (الافتراضي في ووردبريس الحديث): الأمر لا "يُحسّن" بالمعنى نفسه، بل يعيد بناء الجدول فتكون فائدته محدودة. وجود بعض التجزئة في InnoDB أمر طبيعي ولا يستحقّ القلق.

ولنكسر الأسطورة صراحةً، لأنّها منتشرة بما يستحقّ التفصيل. حين تشغّل OPTIMIZE TABLE على جدول InnoDB، لا يوجد أمر "تحسين" أصيل لهذا المحرّك أصلًا، فتصمّم MySQL على تحويله ضمنيًّا إلى ALTER TABLE … FORCE، أي إعادة بناء الجدول من الصفر ونسخه بالكامل ثمّ استبداله. النتيجة أنّه يستعيد بعض المساحة لنظام التشغيل ويعيد ترتيب الصفحات، لكنه لا يفعل السحر الذي تتوقّعه: مساحة InnoDB "المهدرة" (ما تسمّيه واجهات مثل phpMyAdmin بالـoverhead) ليست مهدرةً بالمعنى الحرفيّ، بل هي غالبًا صفحات محجوزة يعيد InnoDB استخدامها تلقائيًّا حين تُدرَج بيانات جديدة. فأنت بإعادة البناء تحرّرها الآن ليعيد المحرّك حجزها لاحقًا — دورة عبثيّة في أغلب الأحيان.

وله ثمن حقيقيّ يجب أن تعيه: إعادة البناء تتطلّب مساحة قرص مؤقّتة تعادل حجم الجدول نفسه (لأنّه ينسخه)، وتضغط الإدخال/الإخراج بشدّة على جدول كبير، وقد تعطّل الكتابة أثناءها على بعض التكوينات. على جدول wp_postmeta بعدّة غيغابايت، قد يستغرق هذا دقائق يعاني فيها موقعك. لهذا الفارق العمليّ الحاسم: على MyISAM الأمر يقدّم فائدة ملموسة (إزالة تجزئة حقيقية) مقابل قفل الجدول، أمّا على InnoDB فالفائدة هامشيّة والتكلفة قائمة — تدفع الثمن نفسه تقريبًا مقابل مردود أقلّ بكثير. القاعدة: على InnoDB لا تشغّل OPTIMIZE TABLE روتينيًّا؛ احجزه لحالة واحدة استثنائية — بعد حذف ضخم لمرّة واحدة (ملايين الصفوف) تريد بعده استرجاع مساحة القرص فعلًا للنظام. خارج هذه الحالة، هو ضجيج لا قيمة له.

الخلاصة العملية: لا تبالغ في أهمّية OPTIMIZE TABLE نفسه. القيمة الحقيقية للتنظيف تأتي من حذف الصفوف الزائدة (المراجعات، الترانزيانت، السبام، اليتيمة) وتقليص autoload — لا من أمر التحسين ذاته. wp db optimize أو زرّ "تحسين الجداول" في الإضافات خطوة ختامية لطيفة تستعيد بعض المساحة بعد الحذف، لكنها ليست البطل. إن قضيت وقتك كله في الضغط على "تحسين" دون معالجة مصادر التضخّم، فأنت تلمّع سطحًا لا تنظّفه.

التنظيف بالإضافات: راحة مقابل مخاطرة

ليس كل مالك موقع مرتاحًا مع SQL أو SSH، وهنا تأتي إضافات التنظيف. تقدّم واجهة أزرار لكل ما شرحناه، مع جدولة تلقائية. لكن لكل راحةٍ ثمن، وثمن هذه الإضافات هو فقدان الرؤية: تضغط زرًّا فتحذف الإضافة أشياء لا تراها. لهذا القاعدة عند استخدامها: افهم ماذا يفعل كل خيار قبل تفعيله، وابدأ بلا جدولة عدوانية.

الحدّ المشترك بين كل إضافات التنظيف — بما فيها هاتان — أمران يجب أن تعيهما جيّدًا:

أوّلًا، الجدولة العدوانية قد تحذف مطلوبًا. إذا ضبطت الإضافة لتنظّف يوميًّا وتشمل "المهملات"، فقد تمسح مقالًا حذفته بالخطأ قبل أن تلاحظ. اجعل الجدولة محافِظة: الترانزيانت المنتهية أسبوعيًّا مقبول، أمّا المهملات والمراجعات فأبقِها بقرار يدوي.

ثانيًا، كشف "اليتيم" ليس معصومًا. حين تخبرك إضافة أنّ 5000 صفّ في wp_postmeta "يتيمة"، فهذا حكمها هي بناءً على منطقها. بعض هذه الصفوف قد تخصّ إضافة نشطة تخزّن بياناتها بطريقة غير تقليدية. لهذا: راجع القائمة قبل الحذف، ولا تحذف دفعة واحدة كل ما تسمّيه الإضافة يتيمًا، وخذ نسخة احتياطية أوّلًا حتمًا.

ولأنّ هاتين الإضافتين هما الأكثر شيوعًا، يستحقّ التمييز بينهما تفصيلًا أعمق حتى تختار بوعي لا بعشوائية. WP-Optimize فلسفتها "المنصّة الشاملة": تنظيف قاعدة + كاش صفحات + ضغط صور في إضافة واحدة، بواجهة عربية مريحة وأزرار واضحة لكل نوع تنظيف. قوّتها هي ضعفها في آنٍ: الشمول يعني أنّك تحمّل محرّك كاش كاملًا وأداة ضغط صور قد لا تريدهما لمجرّد أنّك أردت حذف مراجعات. وإن كنت تستخدم إضافة كاش أخرى (كثيرون يفعلون)، فتشغيل كاش WP-Optimize فوقها يخلق تعارضًا. نصيحة عملية: إن اخترتها، فعطّل مكوّنات الكاش والصور من إعداداتها واستخدمها لوظيفة التنظيف فقط، وراجع جدولتها الافتراضية لأنّها قد تأتي أكثر عدوانيةً ممّا تريد.

أمّا Advanced Database Cleaner فتخصّصية لا شاملة: مبنيّة أساسًا لكشف ما لا تراه الأدوات العامة — البيانات اليتيمة، والجداول التي خلّفتها إضافات محذوفة، ومهامّ cron الشاردة (orphaned cron jobs) التي تبقى مجدولةً لإضافة لم تعد موجودة فتستنزف كل تحميل صفحة عبر WP-Cron. هذا آخِر ما تكشفه WP-Optimize، وهو نقطة قوّتها الحقيقية. لكن حدّها الجوهريّ: أقوى ميزاتها — تحديدًا كشف الجداول اليتيمة وتصنيف مهامّ cron المشبوهة — محجوزة في النسخة المدفوعة (Pro) إلى حدّ بعيد؛ النسخة المجانية تعطيك تنظيف الصفوف الأساسي وكشفًا محدودًا للجداول. وحتى مع Pro، كشفها لـ"اليتيم" اجتهاديّ لا قطعيّ: قد تعلّم جدولًا بأنّه يتيم لأنّ إضافته معطّلة مؤقّتًا لا محذوفة، فتحذفه ثمّ تفعّل الإضافة فتنكسر. القاعدة: عاملها كأداة كشف وتشخيص ممتازة، لا كأداة حذف آليّ موثوق؛ دعها ترصد لك المشتبهات، ثمّ احكم أنت على كلّ بند قبل حذفه.

الخلاصة العملية للاختيار: إن أردت تنظيفًا دوريًّا بسيطًا للصفوف الشائعة (مراجعات، ترانزيانت، سبام) وتقبل بأداة شاملة، فـWP-Optimize أوفى. وإن كنت تطارد بقايا إضافات محذوفة تحديدًا — جداول شاردة أو مهامّ cron يتيمة تثقل موقعك — فـAdvanced Database Cleaner أداة الكشف الأنسب، مع وعيك أنّ قيمتها الكبرى وراء جدار النسخة المدفوعة. وفي الحالتين يبقى الحدّ الأخطر قائمًا: أيّ إضافة تنظيف لن تعرف نيّتك، فهي تنفّذ منطقها لا حكمتك — والنسخة الاحتياطية والمراجعة اليدوية قبل الحذف الجماعي يظلّان خطّ دفاعك الأخير مهما كانت الأداة.

إن كنت تبني موقعًا جديدًا وتريد لوحة تحكم نظيفة من البداية، فاطّلع على دليل ووردبريس الكامل لضبط أساساتٍ سليمة تقلّل حاجتك للتنظيف لاحقًا.

خطّة صيانة عملية: بلا إفراط

الخطأ الأشيع بعد قراءة دليل كهذا هو الإفراط: يبدأ صاحب الموقع بتنظيف يومي هوسي، فيقضي وقتًا في مطاردة كل صفّ زائد بينما موقعه بخير. الحقيقة أنّ قاعدة ووردبريس نظام مرن يتحمّل بعض التضخّم دون أثر ملموس. مراجعة كل 3 إلى 6 أشهر تكفي تمامًا لأغلب المواقع، مع الاستثناء الوحيد: راقب autoload بشكل أدقّ إن كان موقعك يثقل بلا سبب واضح.

خطّة معقولة تبدو كالتالي: مرّة كل ربع سنة، خذ نسخة احتياطية، شغّل wp transient delete --expired، احذف المراجعات الزائدة (بعد ضبط WP_POST_REVISIONS لمنع تراكمها)، افحص autoload بالاستعلام أعلاه، ونظّف السبام. ثمّ اترك الموقع بسلام حتى الربع التالي. لا حاجة إلى تنظيف يومي، ولا إلى مطاردة كل ميغابايت. أضِف إلى هذه الخطّة أنّ التنظيف جزء من صيانة أوسع تشمل النسخ الاحتياطي المنتظم لووردبريس والكاش السليم — والثلاثة معًا يبقون موقعك سريعًا وآمنًا.

الاحتياطات: بنودٌ غير قابلة للتفاوض

هذا أهمّ قسم في المقال، وأتركه قرب النهاية عمدًا لتقرأه بعد أن فهمت الأدوات. كل عملية أعلاه آمنة بشرط الالتزام بهذه البنود. تجاهُل أيٍّ منها قد يكلّفك موقعك كله.

• نسخة احتياطية كاملة قابلة للاستعادة قبل أيّ عملية. ليست خيارًا. DELETE في phpMyAdmin بلا رجعة، وخطأ في شرط WHERE يمحو محتوى سنوات في ثانية. راجع دليل النسخ الاحتياطي لووردبريس وتأكّد أنّ نسختك تُستعاد فعلًا لا أنّها موجودة فقط.
• اختبِر على staging أوّلًا إن أمكن. جرّب عمليات التنظيف على نسخة مطابقة قبل الإنتاج، خصوصًا حذف اليتيمة وجداول الإضافات. أغلب المضيفين الجيّدين يوفّرون زرّ إنشاء بيئة staging بنقرة واحدة تستنسخ موقعك بقاعدته كاملةً. سير العمل الآمن: أنشئ staging، شغّل عليها كل عبارات الحذف التي تنوي تشغيلها على الإنتاج، ثمّ تصفّح الموقع فعلًا — افتح مقالات، جرّب نموذج تواصل، ادخل لوحة إضافة حسّاسة، تأكّد أنّ متجرك يعرض المنتجات — قبل أن تكرّر العمليات على الإنتاج. هذا يكشف "اليتيمة زيفًا" قبل أن تؤذيك: إن كسر حذفٌ ما شيئًا، انكسر على النسخة الآمنة لا على موقعك الحيّ. ملاحظة دقيقة: لا تنسخ قاعدة staging المنظّفة فوق الإنتاج ظنًّا أنّك "دمجت" العمل — بيئة staging تجمّد المحتوى لحظة إنشائها، فأيّ طلب أو تعليق أو طلبية وردت على الإنتاج بعدها ستُفقد لو استبدلت. الصحيح أن تعيد تشغيل العبارات المُتحقَّق منها على الإنتاج مباشرةً، لا أن تنقل القاعدة.
• SELECT قبل DELETE دائمًا. عاين ما ستحذفه بعبارة SELECT بنفس الشرط قبل تنفيذ DELETE. رقمٌ صادم في العدّ = توقّف فورًا.
• لا تُفرِط. مراجعة كل 3–6 أشهر تكفي. التنظيف اليومي الهوسي يخلق مخاطر أكثر ممّا يحلّ.
• احذر "اليتيمة زيفًا". بعض ما تسمّيه الإضافات (أو استعلاماتك) يتيمًا يخصّ إضافة نشطة تخزّن بطريقة غير معتادة. تحقّق قبل الحذف الجماعي.
• حذف جلسات WooCommerce يمسح السلال. إن أدرت متجرًا، فتنظيف جلسات الزوّار يمحو سلالهم غير المكتملة. نظّفها من أدوات WooCommerce المخصّصة لا بحذف عشوائي من wp_options. والتفصيل هنا مهمّ لأنّه فخّ يقع فيه كثيرون: يخزّن WooCommerce جلسات الزوّار في جدوله الخاصّ wp_woocommerce_sessions، لا في wp_options كما قد تظنّ، لكنّه يترك بصماتٍ في wp_options على هيئة خيارات ترانزيانت وقفل جلسات (_transient_wc_session_* وأخواتها). فحين ترى أداةُ تنظيف عامةٌ آلاف صفوف _transient_ وتعرض حذفها جميعًا، قد تمسح جلساتٍ نشطة لزوّار يملؤون سلالهم الآن — فتختفي مشترياتهم قبل الدفع وتخسر مبيعاتٍ لن تعرف بها. لهذا في المتاجر: لا تشغّل حذف الترانزيانت الجماعيّ الأعمى، بل استخدم أداة WooCommerce الخاصّة (الحالة ← الأدوات ← Clear customer sessions) التي تحترم الجلسات الحيّة وتحذف المنتهية فقط. وإن اضطررت لحذف ترانزيانت يدويًّا على متجر، استثنِ صراحةً كل ما يبدأ بـ_transient_wc_session_ من الحذف.
• لا تحذف التصنيفات/الوسوم عبر phpMyAdmin مباشرة. بنية التصنيفات موزّعة على ثلاثة جداول مترابطة (wp_terms، wp_term_taxonomy، wp_term_relationships)؛ حذف صفّ من أحدها يدويًّا يكسر التماسك. احذفها من لوحة ووردبريس التي تتولّى الجداول الثلاثة معًا.

التزم بهذه البنود، وسيتحوّل التنظيف من عملية مخيفة إلى صيانة روتينية آمنة. تجاهلها، وقد تجد نفسك تستعيد نسخة احتياطية في أفضل الأحوال، أو تعيد بناء موقعك من الصفر في أسوئها.

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

الأسئلة الشائعة

هل تنظيف قاعدة بيانات ووردبريس يسرّع الموقع فعلًا؟ نعم، لكن بقدرٍ متفاوت. أكبر أثر يأتي من تقليص خيارات autoload المتضخّمة، لأنها تُحمَّل في كل طلب صفحة لكل زائر. حذف المراجعات والترانزيانت يقلّل حجم القاعدة ويسرّع بعض الاستعلامات، لكن أثره أقل دراماتيكية من autoload. أمّا OPTIMIZE TABLE وحده فأثره على السرعة محدود، خصوصًا على محرّك InnoDB الحديث.

ما الفرق بين هذا الدليل ودليل تحسين قاعدة البيانات العام؟ هذا الدليل يخصّ ووردبريس تحديدًا: مراجعات، ترانزيانت، autoload، بيانات يتيمة — صيانة يقوم بها مالك الموقع. أمّا الدليل العام فيتناول التحسين على مستوى المحرّك لأي قاعدة: الفهرسة، ضبط الاستعلامات البطيئة، تكوين خادم MySQL، وكاش الكائنات بـRedis. الاثنان متكاملان، ولا يغني أحدهما عن الآخر.

كم مراجعة يحفظ ووردبريس، وهل حذفها آمن؟ ووردبريس يحفظ مراجعةً عند كل تحديث وكل حفظ تلقائي (كل ~60ث)، فقد يجمع مقال واحد 50 مراجعة أو أكثر. حذفها آمن نسبيًّا، لكن الأفضل استخدام WP-CLI (wp post delete ... --force) لأنّه يحذف البيانات الوصفية المرتبطة معها؛ حذفها بـSQL بسيط يخلّف صفوفًا يتيمة في wp_postmeta.

لماذا لا يحذف ووردبريس الترانزيانت المنتهية تلقائيًّا؟ لأنّ آليّة الترانزيانت "كسولة": ووردبريس لا يفحص كل الترانزيانت باستمرار (سيكون مكلفًا)، بل يتحقّق من انتهاء ترانزيانت عند طلبه فقط. فإذا لم يُطلب ترانزيانت منتهٍ ثانيةً، بقي في wp_options إلى الأبد. لهذا تنظيفه اليدوي أو المجدوَل عبر wp transient delete --expired مفيد.

ما قيمة autoload المثالية، وكيف أعرف قيمتي؟ استهدف بقاء إجمالي حجم خيارات autoload تحت نحو 800 كيلوبايت إلى 1 ميغابايت. لمعرفة قيمتك، شغّل استعلام SUM(LENGTH(option_value)) مع الشرط WHERE autoload IN ('yes','on','auto','auto-on') — انتبه إلى استخدام IN وليس ='yes'، لأنّ ووردبريس 6.6+ يستخدم قيمًا جديدة (on/auto) قد يفوّتها الاستعلام القديم.

هل OPTIMIZE TABLE ضروري بعد كل حذف؟ ليس ضروريًّا بالمعنى الحرج. على InnoDB (الافتراضي الحديث) فائدته محدودة ووجود بعض التجزئة طبيعي. على MyISAM يزيل التجزئة فعلًا لكنه يقفل الجدول لحظيًّا. القيمة الحقيقية في حذف الصفوف الزائدة وتقليص autoload، لا في أمر التحسين نفسه. اعتبره لمسة ختامية اختيارية بعد التنظيف الفعلي.

هل أستخدم إضافة تنظيف أم الأوامر اليدوية؟ إن كنت مرتاحًا مع WP-CLI أو phpMyAdmin، فالطريقة اليدوية تمنحك تحكّمًا ورؤيةً أوضح — وWP-CLI تحديدًا الأنظف لأنّه يحذف المرتبطات. إن لم تكن كذلك، فإضافة مثل WP-Optimize مقبولة بشرط أن تفهم كل خيار وأن تتجنّب الجدولة العدوانية. في الحالتين: نسخة احتياطية أوّلًا، وSELECT/معاينة قبل الحذف.

هل تحذف ثوابت wp-config المراجعات الموجودة؟ لا. ثابت WP_POST_REVISIONS (وأخواته) يوقف النموّ المستقبلي فقط ولا يحذف الموجود. إن كان لديك بالفعل آلاف المراجعات، فاحذفها يدويًّا أو بـWP-CLI أوّلًا، ثمّ يمنع الثابت تراكمها من جديد. الترتيب: نظّف، ثمّ اضبط الثابت للوقاية.

ما البيانات "اليتيمة زيفًا" ولماذا تشكّل خطرًا؟ هي صفوف تبدو بلا أب (مثلًا في wp_postmeta تشير إلى معرّف غير موجود في wp_posts)، لكنها في الحقيقة تخصّ إضافة نشطة تخزّن بياناتها بطريقة غير تقليدية أو تشير إلى معرّفاتها الخاصّة. حذفها الجماعي قد يعطب الإضافة. لهذا: راجع القائمة يدويًّا، ولا تثق بكشف "اليتيم" ثقةً عمياء، وخذ نسخة احتياطية دائمًا.

هل حذف جلسات WooCommerce آمن؟ احذر: جلسات WooCommerce تخزّن سلال الزوّار غير المكتملة. حذفها يمسح هذه السلال، وقد يفقد زوّارك مشترياتهم قبل الدفع. إن احتجت لتنظيفها، فاستخدم أدوات WooCommerce المخصّصة لذلك (التي تحترم صلاحية الجلسات) لا الحذف العشوائي من wp_options.