اثنين من SQL لمزيد من تاريخ الطابع الزمني

Question

لدي بيانات الصفوف 98W.عندما أريد فرز بياناتي باستخدام pub_time، وجدت شيئا فائدة.

هنا هو SQL:

giveacodicetagpre.

تكلف 19s.

giveacodicetagpre.

يكلف 0.2s.

أريد أن أعرف، لماذا؟

Answer 1

ربما يكون لديك فهرس على pub_time على طاولتك.

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

Answer 2

هناك مجموعة من الاحتمالات. يمكنك تصفية أعداد كبيرة من الصفوف مع تواريخ غير صالحة / Null في Pub_Time، لكنني أشك في أنك قد فشلت في ملاحظة / ذكر عدد كبير من هذه.

الأشياء الثلاثة التي تلتصق بها في ذهني هي:

1 - لديك فهرس أو مؤشر مركب ينطوي على PUB_TIME، والقيود في جملة المكان الخاص بك يسبب استخدام مسار وصول مختلف

2 - لم يكن لديك إحصاءات متاحة للمحسن عند ركضت الاستعلام الأول الخاص بك. عند تشغيل الاستعلام الثاني، تم اختيار مسار وصول أفضل بفضل بعض التخزين المؤقت للمعلومات التي حدثت عند تشغيل الاستعلام الأول. يمكن التحقق من ذلك من خلال تشغيل الاستفسار الأول بضع مرات ومعرفة ما إذا كان هناك تحسن كبير في الأداء.

3 - على غرار النقطة الأولى، يمكن أن يختار المحسن مجرد مسار وصول أفضل يعتمد فقط على الآثار المترط بين جملة WHERE. ربما إعطاء تلميحات أن القيم الخالية / غير صالحة لن يتعين التعامل معها كافية - يمكن أن يتجنب نظامك على تجنب واحد أو أكثر من عمليات مسح طاولة كاملة للقشعريرة بصلاحية / null pub_times.

يحدد أسباب أشياء مثل هذا أصبحت بسرعة مغامرة تجريبية - من الصعب علي أن أقول أكثر دون معرفة منصة وإصدارك. من العلامة التي أعتبرها أنت تستخدم Oracle، في هذه الحالة، يجب أن تكون قادرا على استخدام شكل من أشكال "شرح الاستعلام" أو "شرح الخطة" للحصول على إحساس أفضل بما يحدث. لمزيد من المعلومات حول Oracle Optimizer، انظر http://docs.oracle .com / cd / b10500_01 / server.920 / a96533 / optimops.htm (هذا هو لشركة Oracle 9i v9.2، ولكن لديها شرح لائق للمفاهيم المستقلة النسخة)