ستفرض Cloudflare D1 حدًا أقصى لنتائج الاستعلام: ما الذي ينبغي التحقق منه قبل 4 نوفمبر؟

إذا كان تطبيقك يستخرج نتائج كبيرة من Cloudflare D1 في استعلام واحد، فتحقق منه قبل 4 نوفمبر: فمن ذلك التاريخ، سيفشل أي استعلام يعيد أكثر من 50 ميغابايت. يتعلق التغيير بحجم النتيجة، لا بحجم قاعدة البيانات أو حجم الطلب إلى واجهة API؛ وتظل عمليات الاستيراد والتصدير عبر REST API على حالها.

ما الذي سيتغير تحديدًا؟

أعلنت Cloudflare عن هذا الحد في 30 أكتوبر 2026. وتدخل القاعدة الجديدة حيز التنفيذ يوم الأربعاء، 4 نوفمبر: إذا تجاوزت نتيجة استعلام SQL مقدار 50 ميغابايت، فستعيد D1 الخطأ D1 query result exceeded the maximum response size limit of 50 MB. وتشير الشركة إلى أن هذه العتبة تشمل النسبة المئوية 99.999 من استعلامات D1، أي إن الغالبية العظمى من الاستعلامات تظل دون الحد. وهذا تقدير من Cloudflare استنادًا إلى منصتها، وليس ضمانًا لكل تطبيق على حدة.

من المهم التمييز بين نتيجة الاستعلام ونقل البيانات. ينطبق الحد على النتيجة التي يعيدها استعلام D1؛ أما عمليات الاستيراد والتصدير عبر REST API فهي مستثناة صراحةً من القاعدة. لذا ينبغي التركيز في التحقق على استعلامات التطبيق التي تقرأ عددًا كبيرًا من الصفوف أو سجلات واسعة، ثم تسترجعها كاملة.

لماذا قد تظهر نتيجة كبيرة من دون أن تلاحظ ذلك؟

لا يتحدد حجم الاستجابة بعدد الصفوف وحده. فقد يعيد الاستعلام الذي يتضمن أعمدة كثيرة نتيجة كبيرة حتى مع عدد متوسط من السجلات، ولا سيما إذا احتوت الصفوف على نصوص طويلة أو قيم كبيرة أخرى. وتضيف الصيغة SELECT * جميع الأعمدة، مع أن الجهة المستدعية قد لا تحتاج إلا إلى بعضها. كما أن نمو الجدول بمرور الوقت قد يدفع استعلامًا كان آمنًا إلى تجاوز العتبة.

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

كيفية إعداد الاستعلامات

في إشعارها، توصي Cloudflare بتقليص مجموعة البيانات المعادة: اختر الأعمدة المطلوبة بدلًا من استخدام SELECT *، وقسّم عمليات القراءة الكبيرة إلى صفحات باستخدام LIMIT وOFFSET. يقلل هذا الأسلوب حجم كل استجابة، ويساعد على توزيع المعالجة على عدة استعلامات.

1. ابحث عن عمليات القراءة الواسعة. راجع الاستعلامات التي تستخدم SELECT * أو لا تحدد عدد الصفوف أو تتضمن حقولًا نصية كبيرة.
2. ضيّق الأعمدة المحددة. اذكر فقط الأعمدة التي تحتاج إليها فعلًا مرحلة المعالجة التالية.
3. قسّم القراءة إلى دفعات. أضف جلبًا على صفحات باستخدام LIMIT وOFFSET، كما تقترح Cloudflare، وعالج الدفعات بالتتابع.
4. تحقق من السلوك بعد التقسيم. تأكد من أن التطبيق يدمج النتائج على نحو صحيح، ولا يعتمد على استلام مجموعة النتائج كاملة في استجابة واحدة.

إذا كان التطبيق يحتاج إلى مجموعة البيانات كاملة لإجراء عملية تصدير منفصلة، فتحقق مما إذا كانت عملية التصدير عبر REST API مناسبة لهذه المهمة: إذ تذكر Cloudflare صراحةً أن الحد الجديد لا ينطبق عليها. لكن هذا الاستثناء لا يغني عن مراجعة استجابات SQL الكبيرة في منطق التطبيق المعتاد.

من المعني بالموعد النهائي؟

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

يساعد التحقق قبل 4 نوفمبر على اكتشاف الاعتماد على استجابة واحدة كبيرة قبل بدء سريان الحد. ووفقًا لتقدير Cloudflare، تظل العتبة أعلى بكثير من الحجم المعتاد لمعظم الاستعلامات؛ أما الأنظمة المتأثرة، فأبسط خطة لها هي تقليص البيانات المختارة، أو قراءتها على دفعات، أو استخدام مسار REST API المخصص للتصدير.