أطول استعلامات BigQuery مدةً
تحجب الاستعلامات طويلة التشغيل الموارد وتؤخّر خطوط الأنابيب الدفعية وتُحبط المستخدمين في انتظار النتائج. يحدّد هذا الاستعلام أطول الاستعلامات تشغيلاً في مشروعك مع وقت تنفيذها وتكلفتها ونسبة الوقت إلى البايتات التي تساعد في تمييز المسح المشروع على نطاق واسع عن الاستعلامات سيئة التحسين.
لماذا يهم هذا
وقت التنفيذ مهم أكثر من التكلفة وحدها. استعلام يعمل 30 دقيقة يحجب خط أنابيب بيانات ويؤخّر تحديثات لوحة التحكّم أو يجبر المحلل على تغيير السياق. في ظل تسعير Editions، تستهلك الاستعلامات طويلة التشغيل أيضاً ساعات فتحات أكثر (حدّ أدنى دقيقة واحدة للفوترة). يُحسّن تقليل مدة الاستعلام التكلفة والإنتاجية معاً.
كيف يعمل
يحسب الاستعلام وقت التنفيذ كـ TIMESTAMP_DIFF بين end_time وstart_time. كما يحسب نسبة الثواني لكل GiB: تشير القيم العالية إلى استعلامات بطيئة بالنسبة لكمية البيانات التي تعالجها، مما يُشير إلى إمكانية التحسين.
استعلام SQL
Fill in your details to get a ready-to-run query:
-- Slowest queries ranked by wall-clock execution time
DECLARE lookback_days INT64 DEFAULT 7;
WITH jobs AS (
SELECT
user_email,
query,
project_id,
start_time,
end_time,
TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_sec,
COALESCE(total_bytes_billed, 0) AS bytes_billed,
total_slot_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
),
deduplicated AS (
SELECT *, ROW_NUMBER() OVER (PARTITION BY query ORDER BY bytes_billed DESC) AS qrn
FROM jobs WHERE rn = 1
)
SELECT
user_email,
query,
project_id,
start_time,
duration_sec,
ROUND(SAFE_DIVIDE(total_slot_ms, duration_sec * 1000), 0) AS avg_slots,
...شرح الاستعلام
مستويان من إزالة التكرار: أولاً بـ job_id لإزالة إدخالات المهام المكررة، ثم بنص الاستعلام لإظهار التنفيذ الأغلى فقط لكل استعلام فريد. يقسم مقياس sec_per_gib وقت التنفيذ على البايتات المفوترة — تعني القيم العالية أن الاستعلام بطيء بالنسبة لكمية البيانات التي يقرأها.
رؤى أساسية
الاستعلامات التي تتجاوز 10 دقائق تمسح على الأرجح جداول غير مقسّمة أو تُجري عمليات تبديل مكلفة.
ارتفاع sec_per_gib يعني أن الاستعلام مقيّد بالحوسبة (JOINs معقدة وفرز ووظائف نافذة) لا بالإدخال/الإخراج.
انخفاض sec_per_gib يعني أن الاستعلام يمسح الكثير من البيانات بسرعة — قد يستفيد من تقطيع الأقسام.
قد تُفضي الاستعلامات طويلة التشغيل في خطوط الأنابيب إلى تأخيرات متتالية في جميع التبعيات النهائية.
أفضل الممارسات
- 1
اضبط حدود مهلة الاستعلام لمنع الاستعلامات الجامحة من استهلاك الموارد إلى أجلٍ غير مسمى.
- 2
لخطوط أنابيب ETL، قسّم الاستعلامات المونوليثية طويلة التشغيل إلى تحويلات أصغر وذات مراحل.
- 3
استخدم EXPLAIN PLAN لتحديد أبطأ المراحل وتحسينها تحديداً.
- 4
فكّر في وظائف التجميع التقريبي (APPROX_QUANTILES وAPPROX_TOP_COUNT) للاستعلامات الاستكشافية.
هل تريد من CloudClerk إيجاد هذه الوفورات تلقائياً؟
تتصل منصتنا بمشروع BigQuery الخاص بك وتُشغّل هذه التحليلات تلقائياً وتقدّم توصيات التحسين المدعومة بالذكاء الاصطناعي — مع إخفاء هوية بياناتك بالكامل.
أدلة ذات صلة
أعلى استعلامات BigQuery تكلفةً
ابحث عن أغلى استعلامات BigQuery من حيث التكلفة عند الطلب. رتّب الاستعلامات حسب إجمالي البايتات المفوترة لتحديد أكبر محرّكات التكاليف.
اقرأ الدليلأكثر استعلامات BigQuery تعقيداً
ابحث عن أكثر استعلامات BigQuery كثافةً حسابياً مرتّبةً حسب استخدام الفتحات. حدّد الاستعلامات التي تستهلك موارد حسابية غير متناسبة.
اقرأ الدليلأكثر استعلامات BigQuery تكراراً
حدّد الاستعلامات الأكثر تنفيذاً في BigQuery. ابحث عن الاستعلامات المتكررة المرشحة للتخزين المؤقت أو طرق العرض المادية أو الدمج.
اقرأ الدليلاستخدام فتحات BigQuery ساعةً بساعة
راقب استهلاك فتحات BigQuery بالساعة لتحديد نوافذ ذروة الاستخدام وتحسين جدولة حجوزاتك.
اقرأ الدليل