الفهرسة للوحات الإدارة: حسّن الفلاتر الأكثر أهمية أولًا

لماذا تصبح فلاتر لوحات الإدارة بطيئة\n\nلوحات الإدارة عادةً تبدأ سريعة. تفتح قائمة، تمرّر، تضغط سجل، وتتابع. يبدا البطء عندما يستخدم الناس الفلاتر بالطريقة التي يعملون بها فعلاً: "العناصر المفتوحة فقط"، "مخصّص لـ Maya"، "تم الإنشاء الأسبوع الماضي"، "معرّف الطلب يحتوي 1047". كل نقرة تسبب انتظارًا، وتشعر القائمة بالالتصاق.\n\nنفس الجدول يمكن أن يكون سريعًا لفِلتر واحد وبطيئًا جدًا لآخر. فلتر الحالة قد يلامس جزءًا صغيرًا من الصفوف ويعود بسرعة. فلتر "مُنشأ بين تاريخين" قد يجبر قاعدة البيانات على قراءة نطاق ضخم. فلتر المُكلّف قد يكون جيدًا بمفرده، ثم يتباطأ عندما تجمعه مع حالة زائد فرز.\n\nالفهارس هي الاختصار الذي يستخدمه محرك قاعدة البيانات لإيجاد الصفوف المطابقة دون قراءة الجدول بأكمله. لكن الفهارس ليست مجانية. تشغل مساحة، وتجعل الإدراجات والتحديثات أبطأ قليلًا. إضافة الكثير منها قد تبطئ عمليات الكتابة ومع ذلك لا تحل عنق الزجاجة الحقيقي.\n\nبدلًا من فهرسة كل شيء، فضل الفلاتر التي:\n\n- تُستخدم باستمرار\n- تلامس عددًا كبيرًا من الصفوف\n- تخلق انتظارًا ملحوظًا\n- يمكن تحسينها بأمان بفهارس بسيطة ومتطابقة مع الاستعلامات\n\nهذا التركيز متعمد. شكاوى الأداء الأولى في قوائم الإدارة تقريبًا دائمًا تأتي من نفس أربعة أنواع فلاتر: الحالة، المُكلّف، نطاقات التواريخ، والحقول النصية. بمجرد أن تفهم لماذا تتصرف هذه الأنواع بشكل مختلف، تكون الخطوات التالية واضحة: راقب أنماط الاستعلام الحقيقية، أضف أصغر فهرس يطابقها، وتحقق أن الطريق البطيء تحسّن دون خلق مشاكل جديدة.\n\n## أنماط الاستعلام وراء العمل الإداري الحقيقي\n\nلوحات الإدارة نادرًا ما تبطأ بسبب تقرير عملاق واحد. تبطأ لأن بعض الشاشات تُستخدم طوال اليوم، وهذه الشاشات تشغّل الكثير من الاستعلامات الصغيرة مرارًا وتكرارًا.\n\nفرق العمليات عادةً تعمل في حزم عمل محدودة: تذاكر، طلبات، مستخدمون، موافقات، طلبات داخلية. في هذه الصفحات، تتكرر الفلاتر:\n\n- الحالة، لأنها تعكس سير العمل (New، Open، Pending، Done)\n- المُكلّف، لأن الفرق تحتاج "عناصري" و"غير مخصّصة"\n- نطاقات التواريخ، لأن شخصًا ما دائمًا يسأل "ماذا حدث الأسبوع الماضي؟"\n- البحث، إما للقفز إلى عنصر معروف (رقم الطلب، بريد إلكتروني) أو لمسح نص (ملاحظات، معاينات)\n\nعمل قاعدة البيانات يعتمد على النية:\n\n- Browse newest هو نمط مسح. عادة يبدو كـ "عرض أحدث العناصر، ربما مقيدًا بحالة، مرتبًا حسب وقت الإنشاء" ومجزّأ على صفحات.\n- Find a specific item هو نمط بحث مباشر. المشرف لديه معرف أو بريد إلكتروني أو رقم تذكرة ويتوقع أن تنتقل قاعدة البيانات مباشرة إلى مجموعة صغيرة من الصفوف.\n\nلوحات الإدارة أيضًا تجمع الفلاتر بطرق متوقعة: "Open + Unassigned"، "Pending + Assigned to me"، أو "Completed في آخر 30 يومًا". تعمل الفهارس أفضل عندما تطابق أشكال الاستعلام الحقيقية تلك، وليس مجرد قائمة أعمدة.\n\nإذا بنيت أدوات إدارة في AppMaster (appmaster.io)، فهذه الأنماط عادةً تكون مرئية بمجرد النظر إلى شاشات القوائم الأكثر استخدامًا والفلاتر الافتراضية. هذا يجعل من الأسهل فهرسة ما يدفع العمل اليومي فعلاً، لا ما يبدو جيدًا على الورق.\n\n## كيف تختار ما تفهرسه أولًا\n\nعامل الفهرسة كفرز طبيعة الأولويات. لا تبدأ بفهرسة كل عمود يظهر في قائمة الفلاتر. ابدأ بالقليل من الاستعلامات التي تعمل باستمرار وتزعج الناس أكثر.\n\n### اعثر على الفلاتر التي يستخدمها الناس فعلاً\n\nتحسين فلتر لا يلمسه أحد هو جهد ضائع. للعثور على المسارات الساخنة الحقيقية، اجمع إشارات:\n\n- تحليلات الواجهة: أي الشاشات تحصل على أكبر عدد من المشاهدات، وأي الفلاتر تُضغط أكثر\n- سجلات قاعدة البيانات أو API: أكثر الاستعلامات تكرارًا وأبطأ النِسب القليلة\n- ملاحظات فريقية: "البحث بطيء" عادةً يشير إلى شاشة محددة\n- قائمة الهبوط الافتراضية: ما يُنفّذ حالًا عندما يفتح المشرف اللوحة\n\nفي فرق عديدة، هذا العرض الافتراضي يكون شيئًا مثل "التذاكر المفتوحة" أو "الطلبات الجديدة". يُشغَّل في كل مرة يُحدّث فيها أحدهم، يبدّل تبويبات، أو يعود بعد الرد.\n\n### جمّع الاستعلامات حسب الشكل، لا حسب اسم الحقل\n\nقبل إضافة فهرس، جمّع استعلاماتك الشائعة بحسب كيفية عملها. معظم استعلامات قوائم الإدارة تقع في عدد قليل من السِلال:\n\n- فلاتر المكافئة: status = 'open', assignee_id = 42\n- فلاتر النطاق: created_at بين تاريخين\n- الفرز والتصفّح: ORDER BY created_at DESC وجلب الصفحة الثانية\n- عمليات البحث النصي: مطابقة دقيقة (رقم الطلب)، مطابقة بادئة (البريد يبدأ بـ)، أو بحث يحتوي\n\nاكتب شكل كل شاشة من الأعلى، بما في ذلك WHERE وORDER BY والتصفّح. استعلامان قد يبدوان متشابهين في الواجهة لكن يتصرفان بشكل مختلف جدًا في قاعدة البيانات.\n\n### اختر دفعة أولية صغيرة\n\nابدأ بهدف واحد ذي أولوية: استعلام القائمة الافتراضي الذي يحمل أولًا. ثم اختر 2 أو 3 استعلامات ذات تكرار عالٍ أخرى. هذا عادةً يكفي لخفض أكبر التأخيرات دون تحويل قاعدة بياناتك إلى متحف فهارس.\n\nمثال: فريق الدعم يفتح قائمة Tickets مفلترة على status = 'open'، مرتبة بالأحدث، مع مُكلّف ونطاق تاريخ اختياري. حسّن هذا المزيج بالضبط أولًا. عندما يصبح سريعًا، انتقل إلى الشاشة التالية بناءً على الاستخدام.\n\n## فهرسة فلتر الحالة دون الإفراط\n\nالحالة أحد أول الفلاتر التي يضيفها الناس، وهي أيضًا من أسهل الحقول لتطبيق فهرس يُستخدم خطأً.\n\nمعظم حقول الحالة ذات تنوّع منخفض: قيم قليلة فقط (open، pending، closed). يفيد الفهرس أكثر عندما يستطيع تضييق النتائج إلى شريحة صغيرة من الجدول. إذا كانت 80% إلى 95% من الصفوف تشترك في نفس الحالة، ففهرس على status وحده غالبًا لن يغير الكثير. ما يزال على قاعدة البيانات قراءة جزء كبير من الصفوف، والفهرس يضيف عبئًا.\n\nعادةً تشعر بالفائدة عندما:\n\n- تكون حالة واحدة نادرة (مثل escalated)\n- تُجمَع الحالة مع شرط آخر يجعل مجموعة النتائج صغيرة\n- الحالة مع الفرز تطابق عرض قائمة شائع\n\nالنمط الشائع هو "أرني العناصر المفتوحة، الأحدث أولًا." في هذه الحالة، فهرسة الفلتر والفرز معًا غالبًا ما تفوق فهرسة status بمفردها.\n\nالتركيبات التي تميل إلى أن تدفع الفائدة أولًا:\n\n- status + updated_at (تصفية بالحالة، فرز بالتغييرات الأخيرة)\n- status + assignee_id (عوائد قوائم العمل)\n- status + updated_at + assignee_id (فقط إذا كان هذا العرض الدقيق مستخدمًا بكثافة)\n\nالفهارس الجزئية هي حل وسط جيد عندما تسود حالة واحدة. إذا كان العرض الرئيسي هو "open"، فافهرس صفوف open فقط. يبقى الفهرس أصغر وتكلفة الكتابة أقل.\n\n```sql

-- PostgreSQL example: index only open rows, optimized for newest-first lists CREATE INDEX CONCURRENTLY tickets_open_updated_idx ON tickets (updated_at DESC) WHERE status = 'open'; ```\n\nاختبار عملي: شغّل الاستعلام الإداري البطيء مع وبدون فلتر الحالة. إذا كان بطيئًا في الحالتين، ففهرس الحالة وحده لن ينقذه. ركّز على الفرز والفلتر الثاني الذي يضيق القائمة فعلاً.\n\n## فلترة المُكلّف: فهارس المساواة والتركيبات الشائعة\n\nفي معظم لوحات الإدارة، المُكلّف هو معرف مستخدم مخزن على السجل: مفتاح خارجي مثل assignee_id. هذا فلتر مساواة كلاسيكي، وغالبًا ما يكون فوزًا سريعًا بفهرس بسيط.\n\nالمُكلّف يظهر أيضًا مع فلاتر أخرى لأنه يطابق طريقة عمل الناس. قد يفلتر قائد الدعم إلى "مخصّص لـ Alex" ثم يقصر إلى "Open" لرؤية ما تبقى. إذا كان هذا العرض بطيئًا، غالبًا تحتاج لأكثر من فهرس عمود واحد.\n\nنقطة بداية جيدة هي فهرس مركب يطابق مجموعة الفلاتر الشائعة:\n\n- (assignee_id, status) لعرض "عناصري المفتوحة"\n- (assignee_id, status, updated_at) إذا كانت القائمة مرتبة أيضًا بنشاط حديث\n\nترتيب الأعمدة مهم في الفهارس المركبة. ضع فلاتر المساواة أولًا (غالبًا assignee_id ثم status)، وضع عمود الفرز أو النطاق أخيرًا (updated_at). هذا يتماشى مع ما يمكن لقاعدة البيانات استخدامه بكفاءة.\n\nالعنصر الشائع غير المخصّص يمثل مفاجأة عملية. كثير من الأنظمة تمثل "unassigned" كقيمة NULL في assignee_id، والمدراء يفلترون ذلك كثيرًا. حسب قاعدة بياناتك وشكل الاستعلام، قيم NULL قد تغيّر خطة التنفيذ بحيث يفقد الفهرس قدرته.\n\nإذا كانت "غير مخصّصة" جزءًا مهمًا من سير العمل، اختر نهجًا واضحًا واختبره:\n\n- اترك assignee_id قابلاً لأن يكون NULL، لكن تأكد من اختبار WHERE assignee_id IS NULL وفهرسته عند الحاجة.\n- استخدم قيمة مخصصة (مثل مستخدم "Unassigned") فقط إن كانت تناسب نموذج البيانات.\n- أضف فهرسًا جزئيًا للصفوف غير المخصّصة إن كان قاعدة البيانات تدعمه.\n\nإذا كنت تبني لوحة إدارة في AppMaster، فمساعدة أن تسجّل الفلاتر والترتيبات الدقيقة التي يستخدمها فريقك ثم تلفّهى بنماذج فهرس صغيرة ومحددة بدلًا من فهرسة كل حقل متاح.\n\n## نطاقات التواريخ: فهارس تطابق طريقة الفلترة\n\nفلترات التاريخ عادة تظهر كاختصارات سريعة مثل "آخر 7 أيام" أو "آخر 30 يومًا"، بالإضافة إلى منتقي مخصص ببداية ونهاية. تبدو بسيطة، لكنها قد تُحرّك عملًا مختلفًا جدًا على الجداول الكبيرة.\n\nأولًا، كن واضحًا بشأن أي عمود طابع زمني يقصده الناس. استخدم:\n\n- created_at لعرض "العناصر الجديدة"\n- updated_at لعرض "المتغيّرة مؤخرًا"\n\nضع فهرس btree عادي على هذا العمود. بدونه، كل نقرة على "آخر 30 يومًا" يمكن أن تتحول لمسح كامل للجدول.\n\nالمديات الجاهزة غالبًا تبدو كـ created_at >= now() - interval '30 days'. هذا شرط نطاق، وفهرس على created_at يمكن استخدامه بكفاءة. إذا كانت الواجهة أيضًا ترتب بالأحدث أولًا، فمطابقة اتجاه الفرز في الفهرس (مثل created_at DESC في PostgreSQL) قد تساعد على القوائم المستخدمة بكثافة.\n\nعندما تتداخل نطاقات التواريخ مع فلاتر أخرى (الحالة، المُكلّف)، كن انتقائيًا. الفهارس المركبة رائعة عندما يكون المزيج شائعًا. وإلا، فإنها تضيف تكلفة كتابة دون فائدة.\n\nمجموعة قواعد عملية:\n\n- إذا كانت معظم العروض تفلتر حسب الحالة ثم بالتاريخ، فإن (status, created_at) قد يساعد.\n- إذا كانت الحالة اختيارية لكن التاريخ دائمًا موجودًا، احتفظ بفهرس created_at بسيط وتجنّب الكثير من المركبات.\n- لا تنشئ كل توليفة. كل فهرس جديد يزيد التخزين ويبطئ الكتابة.\n\nالمنطقة الزمنية وحدود التواريخ تسبب الكثير من أخطاء "سجلات مفقودة". إذا اختار المستخدمون تواريخ (بدون أوقات)، قرر كيف تفسر تاريخ النهاية. نمط آمن هو بداية شاملة ونهاية حصرية: created_at >= start وcreated_at < end_next_day. خزّن الطوابع الزمنية بالـ UTC وحوّل مدخلات المستخدم إلى UTC قبل الاستعلام.\n\nمثال: مشرف العمليات يختار 10 يناير إلى 12 يناير ويتوقع رؤية العناصر من كل يوم 12. إذا كان استعلامك يستخدم <= '2026-01-12 00:00'، ستفقد تقريبًا كل ما حدث في 12 يناير. الفهرس جيد، لكن منطق الحدود خاطئ.\n\n## الحقول النصية: مطابقة دقيقة مقابل بحث يحتوي\n\nالبحث النصي هو المكان الذي تبطئ فيه الكثير من لوحات الإدارة، لأن الناس يتوقعون صندوقًا واحدًا للعثور على كل شيء. التصحيح الأول هو فصل حاجتين مختلفتين: المطابقة الدقيقة (سريعة ومتوقعة) مقابل بحث يحتوي (مرن لكنه أثقل).\n\nالمطابقة الدقيقة تشمل معرّف الطلب، رقم التذكرة، البريد الإلكتروني، الهاتف، أو مرجع خارجي. هذه مثالية للفهارس العادية. إذا كان المشرفون غالبًا يلصقون معرفًا أو بريدًا إلكترونيًا، ففهرس بسيط مع استعلام مساواة يجعلها فورية تقريبًا.\n\nبحث يحتوي هو عندما يكتب شخص جزءَا مثل "refund" أو "john" ويتوقع التطابق في الأسماء، الملاحظات، والأوصاف. غالبًا يُنفّذ ذلك كـ LIKE %term%. البدل القيادي يمنع استخدام فهرس B-tree العادي، لذا تمسح قاعدة البيانات الكثير من الصفوف.\n\nطريقة عملية لبناء بحث بدون إرهاق قاعدة البيانات:\n\n- اجعل البحث بالمطابقة الدقيقة من الدرجة الأولى (ID، بريد إلكتروني، اسم مستخدم) ووضّحه للمستخدم.\n- لبحث "يبدأ بـ" (term%)، الفهرس العادي غالبًا يساعد ويكفي لأسماء.\n- أضف بحث يحتوي فقط عندما تُظهر السجلات أو الشكاوى حاجته.\n- عندما تضيفه، استخدم الأداة المناسبة (full-text أو trigram في PostgreSQL) بدلًا من الاعتماد على فهرس عادي لتصحيح LIKE %term%.\n\nقواعد إدخال تقلل الحمل وتجعل النتائج متسقة:\n\n- حدّ أدنى لطول العبارة لبحث يحتوي (مثلاً 3+ أحرف).\n- طبع الأحرف أو استخدم مقارنات حساسة لحالة الحروف بشكل ثابت.\n- اقتطع المسافات القيادية والنهاية ودمج المسافات المتكررة.\n- عامل البريد الإلكتروني والمعرّفات كمطابقة دقيقة افتراضيًا حتى لو دخلت في صندوق بحث عام.\n- إن كان المصطلح واسعًا جدًا، اطلب من المستخدم التحديد بدل تشغيل استعلام ضخم.\n\nمثال صغير: مدير الدعم يبحث "ann" لإيجاد عميل. إذا كان نظامك يشغّل LIKE %ann% عبر الملاحظات والأسماء والعناوين، قد يمسح آلاف السجلات. إذا تحققت أولًا من الحقول الدقيقة (البريد أو معرف العميل)، ثم عدت إلى فهرس نصي أذكى عند الحاجة، يبقى البحث سريعًا دون تحول كل استعلام إلى تمرين مكثف لقاعدة البيانات.\n\n## سير عمل خطوة بخطوة لإضافة الفهارس بأمان\n\nالفهارس سهلة الإضافة وسهلة الندم لاحقًا. سير آمن يبقيك مركزًا على الفلاتر التي يعتمد عليها المشرفون، ويساعدك على تجنّب الفهارس "المحتملة" التي تُبطئ الكتابة لاحقًا.\n\nابدأ بالاستخدام الحقيقي. اسحب أعلى الاستعلامات بطريقتين:\n\n- أكثر الاستعلامات تكرارًا\n- أبطأ الاستعلامات\n\nبالنسبة للوحات الإدارة، هذه عادة صفحات قائمة مع فلاتر وفرز.\n\nبعد ذلك، التقط شكل الاستعلام تمامًا كما تراه قاعدة البيانات. اكتب WHERE وORDER BY بدقة، بما في ذلك اتجاه الفرز والتوليفات الشائعة (مثلاً: status = 'open' AND assignee_id = 42 ORDER BY created_at DESC). الفروقات الصغيرة قد تغيّر أي فهرس يساعد.\n\nاستخدم حلقة بسيطة:\n\n- اختر استعلامًا بطيئًا واحدًا وتغيير فهرس واحد لتجربته.\n- أضف أو عدّل فهرسًا واحدًا فقط.\n- أعد القياس بنفس الفلاتر ونفس الفرز.\n- تحقق ألا تكون عمليات الإدراج والتحديث أبطأ بشكل ملحوظ.\n- احتفظ بالتغيير فقط إن حسّن الاستعلام الهدف بوضوح.\n\nالتصفّح بالصفحات يستحق فحصه المستقل. التصفح القائم على الإزاحة (OFFSET 20000) غالبًا يزداد بطئًا كلما ذهبت أعمق، حتى مع الفهارس. إذا كان المستخدمون ينتقلون عادة إلى صفحات عميقة جدًا، فكر في التصفّح بنمط المؤشر ("عرض العناصر قبل هذا الطابع/المعرف") حتى يقوم الفهرس بعمل ثابت على الجداول الكبيرة.\n\nأخيرًا، احتفظ بسجل صغير حتى تظل قائمة الفهارس مفهومة بعد أشهر: اسم الفهرس، الجدول، الأعمدة (والترتيب)، والاستعلام الذي يدعمه.\n\n## أخطاء شائعة في فهرسة لوحات الإدارة\n\nأسرع طريقة لجعل لوحة الإدارة تبدو بطيئة هي إضافة فهارس دون التحقق من كيفية فلات الناس فعلاً وترتيبهم للنتائج. الفهارس تكلف مساحة وتضيف عملًا لكل إدراج وتحديث.\n\n### الأخطاء التي تظهر غالبًا\n\nهذه الأنماط تسبب معظم المشاكل:\n\n- فهرسة كل عمود "للطوارئ".\n- إنشاء فهرس مركب بترتيب أعمدة خاطئ.\n- تجاهل الفرز والتصفّح.\n- توقع أن فهرسًا عاديًا سيحل مشكلة LIKE '%term%'.\n- ترك فهارس قديمة بعد تغيّر الواجهة.\n\nسيناريو شائع: فريق الدعم يفلتر التذاكر بـ Status = Open، يفرز حسب وقت التحديث، ويتصفح النتائج. إذا أضفت فهرسًا على status فقط، قد تضطر قاعدة البيانات لجمع كل التذاكر المفتوحة وفرزها. فهرس يطابق الفلتر والفرز معًا يمكنه إعادة الصفحة الأولى بسرعة.\n\n### طرق سريعة لالتقاط هذه المشاكل\n\nقبل وبعد تغييرات واجهة الإدارة، قم بمراجعة قصيرة:\n\n- اذكر أبرز الفلاتر والترتيب الافتراضي، ثم تحقق من وجود فهرس يطابق نمط WHERE + ORDER BY.\n- تحقق من البدل القيادي (LIKE '%term%') وقرر إن كان بحث يحتوي ضروريًا.\n- ابحث عن فهارس مكررة أو متداخلة.\n- راقب الفهارس غير المستخدمة لفترة، ثم أزلها عندما تتأكد أنها غير مطلوبة.\n\nإذا كنت تبني لوحات إدارة في AppMaster على PostgreSQL، اجعل هذه المراجعة جزءًا من نشر الشاشات الجديدة. الفهارس الصحيحة عادةً تتبع مباشرة من الفلاتر وأوامر الفرز التي تستخدمها الواجهة فعليًا.\n\n## فحوصات سريعة وخطوات لاحقة\n\nقبل إضافة مزيد من الفهارس، تأكد أن الفهارس الموجودة تساعد الفلاتر الدقيقة التي يستخدمها الناس كل يوم. لوحة إدارة جيدة تشعر باللحظة على المسارات الشائعة، لا على عمليات البحث النادرة.\n\nبعض الفحوصات تلتقط معظم المشاكل:\n\n- افتح توليفات الفلاتر الأكثر شيوعًا (الحالة، المُكلّف، نطاق التاريخ، مع الفرز الافتراضي) وتأكد أنها تظل سريعة مع نمو الجدول.\n- لكل عرض بطيء، تحقق أن الاستعلام يستخدم فهرسًا يطابق كل من WHERE وORDER BY، وليس قطعة واحدة فقط.\n- احتفظ بقائمة فهارسك صغيرة بما يكفي لتشرح هدف كل فهرس في جملة واحدة.\n- راقب الإجراءات المكثفة على الكتابة (إنشاء، تحديث، تغيير حالة). إذا أصبحت أبطأ بعد إضافة الفهارس، فقد يكون لديك فهارس كثيرة أو متداخلة.\n- قرر ماذا يعني "البحث" في واجهتك: مطابقة دقيقة، بادئة، أم يحتوي. خطة الفهرسة يجب أن تطابق هذا الاختيار.\n\nخطوة عملية تالية هي كتابة مساراتك الذهبية بجمل بسيطة، مثل: "وكلاء الدعم يفلترون التذاكر المفتوحة، المخصّصة لي، آخر 7 أيام، مرتبة بالأحدث." استخدم هذه الجمل لتصميم مجموعة صغيرة من الفهارس التي تدعمها بوضوح.\n\nإذا كنت لا تزال في المراحل المبكرة من البناء، يساعدك تصميم نموذج بياناتك والفلاتر الافتراضية قبل إنشاء الكثير من الشاشات. مع AppMaster (appmaster.io)، يمكنك التكرار على عروض الإدارة بسرعة، ثم إضافة بضعة فهارس تطابق ما يستخدمه فريقك فعلاً عندما تظهر المسارات الساخنة.