> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# إعدادات الجلسة min_*

> إعدادات جلسة ClickHouse ضمن المجموعة المُنشأة min_*.

export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
  return <div className="not-prose" style={{
    display: "flex",
    flexWrap: "wrap",
    alignItems: "baseline",
    columnGap: "0.5rem",
    rowGap: "0.125rem",
    margin: "0.375rem 0",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <div style={{
    fontWeight: 600,
    opacity: 0.72
  }}>النوع</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>القيمة الافتراضية</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          يمكن تغييره دون إعادة التشغيل
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

تتوفر هذه الإعدادات في [system.settings](/docs/ar/reference/system-tables/settings)، وهي مُولَّدة تلقائيًا من [الشفرة المصدرية](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp).

<div id="min_chunk_bytes_for_parallel_parsing">
  ## min\_chunk\_bytes\_for\_parallel\_parsing
</div>

<SettingsInfoBlock type="NonZeroUInt64" default_value="10485760" />

* النوع: عدد صحيح غير موقّع
* القيمة الافتراضية: 1 MiB

الحد الأدنى لحجم الجزء، بالبايت، الذي سيحلّله كل خيط تنفيذ بالتوازي.

<div id="min_compress_block_size">
  ## min\_compress\_block\_size
</div>

<SettingsInfoBlock type="UInt64" default_value="65536" />

لجداول [MergeTree](/docs/ar/reference/engines/table-engines/mergetree-family/mergetree). لتقليل زمن الاستجابة عند معالجة الاستعلامات، تُضغط كتلة عند كتابة العلامة التالية إذا كان حجمها لا يقل عن `min_compress_block_size`. والقيمة الافتراضية هي 65,536.

أما الحجم الفعلي للكتلة، فإذا كانت البيانات غير المضغوطة أقل من `max_compress_block_size`، فلن يكون أقل من هذه القيمة ولا أقل من حجم البيانات الخاص بعلامة واحدة.

لننظر إلى مثال. افترض أن `index_granularity` ضُبطت على 8192 عند إنشاء الجدول.

لنفترض أننا نكتب عمودًا من النوع UInt32 (4 بايت لكل قيمة). عند كتابة 8192 صفًا، سيكون الإجمالي 32 كيلوبايت من البيانات. وبما أن min\_compress\_block\_size = 65,536، فستُنشأ كتلة مضغوطة لكل علامتين.

ولنفترض أننا نكتب عمود URL من النوع String (بمتوسط حجم 60 بايت لكل قيمة). عند كتابة 8192 صفًا، سيكون المتوسط أقل قليلًا من 500 كيلوبايت من البيانات. وبما أن هذا أكبر من 65,536، فستُنشأ كتلة مضغوطة لكل علامة. وفي هذه الحالة، عند قراءة البيانات من القرص ضمن نطاق علامة واحدة، لن يجري فك ضغط بيانات إضافية.

<Note>
  هذا إعداد مخصص للخبراء، ويُفضَّل عدم تغييره إذا كنت لا تزال في بداية استخدام ClickHouse.
</Note>

<div id="min_filtered_ratio_for_lazy_final">
  ## min\_filtered\_ratio\_for\_lazy\_final
</div>

<SettingsInfoBlock type="Float" default_value="0.5" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "26.4"},{"label": "0.5"},{"label": "إعداد جديد للحد الأدنى لنسبة العلامات المُصفّاة لمتابعة تحسين FINAL الكسول"}]}]} />

الحد الأدنى لنسبة العلامات التي تُصفّيها عملية تحليل الفهرس لتحسين FINAL الكسول. إذا كانت نسبة العلامات المُصفّاة أقل من هذه النسبة، فسيتم الرجوع إلى FINAL العادي. تؤدي القيمة 0 إلى تعطيل هذا التحقق.

<div id="min_hit_rate_to_use_consecutive_keys_optimization">
  ## min\_hit\_rate\_to\_use\_consecutive\_keys\_optimization
</div>

<SettingsInfoBlock type="Float" default_value="0.5" />

الحد الأدنى لمعدل الإصابة لذاكرة التخزين المؤقت المستخدمة في تحسين المفاتيح المتتالية في التجميع للإبقاء عليه مفعّلًا

<div id="min_os_cpu_wait_time_ratio_to_throw">
  ## min\_os\_cpu\_wait\_time\_ratio\_to\_throw
</div>

<SettingsInfoBlock type="Float" default_value="0" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.5"},{"label": "0"},{"label": "تم تغيير قيم الإعداد ونُقلت إلى 25.4"}]}, {"id": "row-2","items": [{"label": "25.4"},{"label": "0"},{"label": "إعداد جديد"}]}]} />

الحد الأدنى للنسبة بين وقت انتظار CPU في نظام التشغيل (المقياس OSCPUWaitMicroseconds) ووقت انشغاله (المقياس OSCPUVirtualTimeMicroseconds) لبدء النظر في رفض الاستعلامات. يُستخدم الاستيفاء الخطي بين الحد الأدنى والحد الأقصى للنسبة لحساب الاحتمال، ويكون الاحتمال عند هذه النقطة 0.

<div id="min_outstreams_per_resize_after_split">
  ## min\_outstreams\_per\_resize\_after\_split
</div>

<SettingsInfoBlock type="UInt64" default_value="24" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.6"},{"label": "24"},{"label": "إعداد جديد."}]}]} />

يحدّد الحد الأدنى لعدد تدفقات الإخراج للمعالج `Resize` أو `StrictResize` بعد تنفيذ عملية التقسيم أثناء إنشاء خط المعالجة. وإذا كان عدد التدفقات الناتج أقل من هذه القيمة، فلن تُجرى عملية التقسيم.

<div id="what-is-a-resize-node">
  ### ما هي عقدة Resize
</div>

تُعدّ عقدة `Resize` معالجًا ضمن مسار تنفيذ الاستعلام يضبط عدد تدفقات البيانات المارة عبر خط المعالجة. ويمكنها زيادة عدد التدفقات أو تقليله لموازنة عبء العمل عبر عدة خيوط تنفيذ أو معالجات. على سبيل المثال، إذا كان الاستعلام يتطلب قدرًا أكبر من التوازي، يمكن لعقدة `Resize` تقسيم تدفق واحد إلى عدة تدفقات. وبالمقابل، يمكنها دمج عدة تدفقات في عدد أقل من التدفقات لتوحيد معالجة البيانات.

تضمن عقدة `Resize` توزيع البيانات بالتساوي عبر التدفقات مع الحفاظ على بنية كتل البيانات. ويساعد ذلك على تحسين استخدام الموارد ورفع أداء الاستعلام.

<div id="why-the-resize-node-needs-to-be-split">
  ### لماذا يلزم تقسيم عقدة Resize
</div>

أثناء تنفيذ خط المعالجة، يحدث تنازع شديد على ExecutingGraph::Node::status\_mutex الخاص بعقدة `Resize` المركزية، لا سيّما في البيئات ذات العدد الكبير من الأنوية، ويؤدي هذا التنازع إلى:

1. زيادة زمن الانتظار في ExecutingGraph::updateNode، مما يؤثر مباشرةً في أداء الاستعلام.
2. هدر قدر كبير من دورات CPU في تنازع القفل الدوراني (native\_queued\_spin\_lock\_slowpath)، مما يضعف الكفاءة.
3. انخفاض استخدام CPU، مما يحدّ من التوازي والإنتاجية.

<div id="how-the-resize-node-gets-split">
  ### كيفية تقسيم عقدة Resize
</div>

1. يُتحقَّق من عدد تدفقات الإخراج للتأكد من إمكانية إجراء التقسيم: بحيث تفي تدفقات الإخراج لكل معالج ناتج عن التقسيم بعتبة `min_outstreams_per_resize_after_split` أو تتجاوزها.
2. تُقسَّم عقدة `Resize` إلى عقد `Resize` أصغر ذات عدد متساوٍ من المنافذ، بحيث تتولى كل منها مجموعة فرعية من تدفقات الإدخال والإخراج.
3. تُعالَج كل مجموعة بشكل مستقل، مما يقلل التنازع على القفل.

<div id="splitting-resize-node-with-arbitrary-inputsoutputs">
  ### تقسيم عقدة Resize بمدخلات/مخرجات بعدد اعتباطي
</div>

في بعض الحالات، عندما لا يكون عدد المدخلات/المخرجات قابلاً للقسمة على عدد عقد `Resize` المُقسَّمة، تُوصَل بعض المدخلات بـ `NullSource`s وتُوصَل بعض المخرجات بـ `NullSink`s. يتيح ذلك إجراء التقسيم من دون التأثير في تدفّق البيانات الإجمالي.

<div id="purpose-of-the-setting">
  ### الغرض من الإعداد
</div>

يضمن الإعداد `min_outstreams_per_resize_after_split` أن يكون تقسيم عُقد `Resize` ذا جدوى، ويمنع إنشاء عدد قليل جدًا من التدفقات، مما قد يؤدي إلى المعالجة المتوازية بصورة غير فعّالة. ومن خلال فرض حد أدنى لعدد تدفقات الإخراج، يساعد هذا الإعداد في الحفاظ على توازن بين التوازي والكلفة الإضافية، مما يُحسّن تنفيذ الاستعلام في السيناريوهات التي تتضمن تقسيم التدفقات ودمجها.

<div id="disabling-the-setting">
  ### تعطيل الإعداد
</div>

لتعطيل تقسيم عُقد `Resize`، اضبط هذا الإعداد على 0. سيؤدي ذلك إلى منع تقسيم عُقد `Resize` أثناء إنشاء خط المعالجة، مما يسمح لها بالاحتفاظ ببنيتها الأصلية من دون تجزئتها إلى عُقد أصغر.

<div id="min_table_rows_to_use_projection_index">
  ## min\_table\_rows\_to\_use\_projection\_index
</div>

<SettingsInfoBlock type="UInt64" default_value="1000000" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.11"},{"label": "1000000"},{"label": "إعداد جديد"}]}]} />

إذا كان العدد التقديري للصفوف المراد قراءتها من الجدول أكبر من هذه العتبة أو مساويًا لها، فسيحاول ClickHouse استخدام فهرس الإسقاط أثناء تنفيذ الاستعلام.