أكثر استعلامات BigQuery تعقيداً
يُقاس التعقيد في BigQuery باستهلاك الفتحات — متوسط عدد الفتحات التي يستخدمها الاستعلام خلال التنفيذ. يرتّب هذا الاستعلام جميع الاستعلامات حسب عدد فتحاتها التقريبي، مكشوفاً أكثر العمليات كثافةً حسابياً في مشروعك.
لماذا يهم هذا
الاستعلامات ذات الفتحات العالية تؤثر على الجميع في مشروعك. في ظل التسعير عند الطلب، تتنافس على حصة تخصيص الفتحات المنصفة (2,000 فتحة عادةً). في ظل تسعير Editions، تستهلك مباشرةً سعتك المحجوزة. تحديد الاستعلامات المعقدة وتحسينها يُحسّن الأداء لجميع المستخدمين ويقلّل التكاليف في كلا نموذجَي الفوترة.
كيف يعمل
يُحسب عدد الفتحات التقريبي بقسمة total_slot_ms على وقت التنفيذ بالمللي ثانية. استعلام استخدم 1,000 فتحة مللي ثانية خلال ثانية واحدة استخدم في المتوسط فتحةً واحدةً تقريباً. يلتقط هذا المقياس التوازي والثقل الحسابي لكل استعلام.
استعلام SQL
Fill in your details to get a ready-to-run query:
-- Queries ranked by average slot consumption (most compute-heavy first)
DECLARE lookback_days INT64 DEFAULT 14;
WITH jobs AS (
SELECT
user_email,
query,
project_id,
start_time,
end_time,
total_slot_ms,
COALESCE(total_bytes_billed, 0) AS bytes_billed,
TIMESTAMP_DIFF(end_time, start_time, MILLISECOND) AS duration_ms,
ROW_NUMBER() OVER (PARTITION BY job_id ORDER BY end_time DESC) AS rn
FROM `your-project`.`region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL lookback_days DAY)
AND job_type = 'QUERY' AND state = 'DONE' AND total_slot_ms IS NOT NULL
)
SELECT
user_email,
query,
project_id,
start_time,
end_time,
ROUND(SAFE_DIVIDE(total_slot_ms, duration_ms), 0) AS avg_slots,
ROUND(duration_ms / 1000, 1) AS duration_sec,
ROUND(bytes_billed / POW(1024, 4) * 6.25, 2) AS on_demand_cost_usd
FROM jobs
WHERE rn = 1
...شرح الاستعلام
الصيغة الأساسية هي SAFE_DIVIDE(total_slot_ms, duration_ms). إذا استخدم استعلام 10,000 فتحة مللي ثانية خلال 100 مللي ثانية، فإن عدد فتحاته التقريبي هو 100 — أي استخدم نحو 100 فتحة في آنٍ واحد. تشير الأرقام الأعلى إلى مزيد من التوازي والطلب الحسابي الأكبر.
رؤى أساسية
الاستعلامات التي تتجاوز 500 فتحة تُعدّ عالية التعقيد وقد تستفيد من إعادة الكتابة.
عدد فتحات عالٍ مع بايتات مفوترة منخفضة يُشير إلى عمليات مكثّفة حسابياً: JOINs معقدة أو وظائف نافذة أو DISTINCT على مجموعات بيانات كبيرة.
عدد فتحات عالٍ مع بايتات عالية يشير إلى مشكلات حجم بيانات وحوسبة معاً — أكبر أهداف التحسين.
قارن عدد الفتحات بوقت التنفيذ: إذا كانت الفتحات عالية لكن التنفيذ سريع، فالاستعلام متوازٍ بكفاءة لكنه كثيف الموارد.
أفضل الممارسات
- 1
بسّط JOINs متعددة الاتجاهات بالتجميع المسبق أو استخدام جداول وسيطة.
- 2
استبدل COUNT(DISTINCT ...) الدقيق بـ APPROX_COUNT_DISTINCT() عندما لا تكون الدقة حاسمة.
- 3
تجنّب الاستعلامات الفرعية المرتبطة — أعد كتابتها كـ JOINs أو وظائف نافذة.
- 4
استخدم التجميع على مفاتيح JOIN لتقليل عمليات التبديل.
هل تريد من CloudClerk إيجاد هذه الوفورات تلقائياً؟
تتصل منصتنا بمشروع BigQuery الخاص بك وتُشغّل هذه التحليلات تلقائياً وتقدّم توصيات التحسين المدعومة بالذكاء الاصطناعي — مع إخفاء هوية بياناتك بالكامل.
أدلة ذات صلة
أعلى استعلامات BigQuery تكلفةً
ابحث عن أغلى استعلامات BigQuery من حيث التكلفة عند الطلب. رتّب الاستعلامات حسب إجمالي البايتات المفوترة لتحديد أكبر محرّكات التكاليف.
اقرأ الدليلأطول استعلامات BigQuery مدةً
ابحث عن أطول استعلامات BigQuery وقت تشغيل. حدّد الاستعلامات البطيئة التي تحجب الموارد وتؤثر على تجربة المستخدم.
اقرأ الدليلأكثر استعلامات BigQuery تكراراً
حدّد الاستعلامات الأكثر تنفيذاً في BigQuery. ابحث عن الاستعلامات المتكررة المرشحة للتخزين المؤقت أو طرق العرض المادية أو الدمج.
اقرأ الدليلاستخدام فتحات BigQuery بالدقيقة
احصل على بيانات استهلاك فتحات BigQuery بالدقيقة. ضروري لتشخيص مشكلات الأداء وفهم طلب الفتحات المتفجّر.
اقرأ الدليل