> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# تجنّب `OPTIMIZE FINAL`

> صفحة توضّح سبب ضرورة تجنّب بند OPTIMIZE FINAL في ClickHouse

تخزّن جداول ClickHouse التي تستخدم **محرك MergeTree** البيانات على القرص على هيئة **أجزاء غير قابلة للتغيير**، ويُنشأ جزء جديد منها في كل مرة يتم فيها insert للبيانات.

تنشئ كل عملية insert جزءًا جديدًا يحتوي على ملفات أعمدة مرتّبة ومضغوطة، إلى جانب بيانات وصفية مثل الفهارس وقيم التحقق. للحصول على وصف مفصل لبنية الأجزاء وكيفية تكوّنها، نوصي بهذا [الدليل](/ar/concepts/core-concepts/parts).

ومع مرور الوقت، تدمج العمليات التي تعمل في الخلفية الأجزاء الأصغر في أجزاء أكبر لتقليل التجزئة وتحسين أداء الاستعلامات.

<Image img="/images/bestpractices/simple_merges.png" size="md" alt="عمليات دمج بسيطة" />

ورغم أنه قد يكون من المغري تشغيل هذا الدمج يدويًا باستخدام:

```sql theme={null}
OPTIMIZE TABLE <table> FINAL;
```

**يجب تجنّب العملية `OPTIMIZE FINAL` في معظم الحالات** لأنها تبدأ
عمليات كثيفة الاستهلاك للموارد قد تؤثر في أداء الـ cluster.

<Info>
  **`OPTIMIZE FINAL` مقابل `FINAL`**

  `OPTIMIZE FINAL` ليس هو نفسه `FINAL`، والذي يكون استخدامه ضروريًا أحيانًا
  للحصول على نتائج من دون تكرار، كما هو الحال مع `ReplacingMergeTree`. وبشكل عام،
  لا بأس باستخدام `FINAL` إذا كانت استعلاماتك تُجري التصفية على الأعمدة نفسها
  الموجودة في المفتاح الأساسي.
</Info>

<div id="why-avoid">
  ## لماذا ينبغي تجنّب ذلك؟
</div>

<div id="its-expensive">
  ### إنه مكلف
</div>

يؤدي تشغيل `OPTIMIZE FINAL` إلى إجبار ClickHouse على دمج **جميع** الأجزاء النشطة في **جزء واحد**، حتى لو كانت عمليات دمج كبيرة قد أُجريت بالفعل. ويتضمن ذلك:

1. **فك ضغط** جميع الأجزاء
2. **دمج** البيانات
3. **إعادة ضغطها**
4. **كتابة** الجزء النهائي إلى القرص أو إلى التخزين الكائني

هذه الخطوات **كثيفة الاستهلاك لوحدة المعالجة المركزية (CPU) وعمليات الإدخال/الإخراج**، وقد تُشكل عبئًا كبيرًا على نظامك، خاصةً عند التعامل مع مجموعات بيانات كبيرة.

<div id="it-ignores-safety-limits">
  ### يتجاهل حدود الأمان
</div>

في الوضع العادي، يتجنب ClickHouse دمج الأجزاء التي يزيد حجمها على \~150 GB (يمكن ضبط ذلك عبر [max\_bytes\_to\_merge\_at\_max\_space\_in\_pool](/ar/reference/settings/merge-tree-settings#max_bytes_to_merge_at_max_space_in_pool)). لكن `OPTIMIZE FINAL` **يتجاوز وسيلة الحماية هذه**، ما يعني:

* قد يحاول دمج **عدة أجزاء بحجم 150 GB** في جزء واحد هائل
* قد يؤدي ذلك إلى **أوقات دمج طويلة**، و**ضغط على الذاكرة**، أو حتى **أخطاء نفاد الذاكرة**
* قد تصبح هذه الأجزاء الكبيرة صعبة الدمج، أي إن محاولات دمجها لاحقًا قد تفشل للأسباب المذكورة أعلاه. وفي الحالات التي تكون فيها عمليات الدمج مطلوبة لضمان سلوك صحيح وقت الاستعلام، فقد يؤدي ذلك إلى عواقب غير مرغوبة، مثل [تراكم السجلات المكررة في ReplacingMergeTree](/ar/concepts/features/operations/insert/deduplication#using-replacingmergetree-for-upserts)، مما يضعف الأداء وقت الاستعلام.

<div id="let-background-merges-do-the-work">
  ## دع عمليات الدمج في الخلفية تتولى المهمة
</div>

ينفّذ ClickHouse بالفعل عمليات دمج ذكية في الخلفية لتحسين كفاءة التخزين والاستعلامات. وهي تدريجية، ومراعية للموارد، وتلتزم بالعتبات المُعدّة. ما لم تكن لديك حاجة محددة جدًا (مثل إنهاء البيانات قبل تجميد جدول أو تصديرها)، **فمن الأفضل عادةً ترك ClickHouse يدير عمليات الدمج تلقائيًا**.