أقترح عليك قراءة نص تقرير فلاديمير سيتنيكوف في أوائل عام 2016 "PostgreSQL وJDBC يستخرجان كل العصير"
مساء الخير اسمي فلاديمير سيتنيكوف. لقد عملت في NetCracker لمدة 10 سنوات. وأنا في الغالب مهتم بالإنتاجية. كل ما يتعلق بـ Java، كل ما يتعلق بـ SQL هو ما أحبه.
واليوم سأتحدث عما واجهناه في الشركة عندما بدأنا باستخدام PostgreSQL كخادم قاعدة بيانات. ونحن نعمل في الغالب مع جافا. لكن ما سأخبركم به اليوم لا يتعلق فقط بجافا. وكما أظهرت الممارسة، يحدث هذا أيضًا في اللغات الأخرى.
نحن سوف نتكلم:
- حول أخذ عينات البيانات.
- حول حفظ البيانات.
- وأيضا عن الأداء.
- وعن المكابس تحت الماء المدفونة هناك.
لنبدأ بسؤال بسيط. نختار صفًا واحدًا من الجدول بناءً على المفتاح الأساسي.
تقع قاعدة البيانات على نفس المضيف. وكل هذه الزراعة تستغرق 20 مللي ثانية.
هذه الـ 20 ميلي ثانية كثيرة. إذا كان لديك 100 طلب من هذا القبيل، فإنك تقضي وقتًا في الثانية في تصفح هذه الطلبات، أي أننا نضيع الوقت.
نحن لا نحب أن نفعل هذا وننظر إلى ما تقدمه لنا القاعدة لهذا الغرض. توفر لنا قاعدة البيانات خيارين لتنفيذ الاستعلامات.
الخيار الأول هو طلب بسيط. ما هو الجيد في ذلك؟ حقيقة أننا نأخذها ونرسلها، ولا شيء أكثر من ذلك.
تحتوي قاعدة البيانات أيضًا على استعلام متقدم، وهو أكثر صعوبة ولكنه أكثر وظيفية. يمكنك إرسال طلب منفصل للتحليل والتنفيذ والربط المتغير وما إلى ذلك.
الاستعلام الموسع الفائق هو أمر لن نغطيه في التقرير الحالي. ربما نريد شيئاً من قاعدة البيانات وهناك قائمة أمنيات تم تشكيلها بشكل ما، أي هذا ما نريده، لكنه مستحيل الآن وفي العام المقبل. لذلك قمنا بتسجيله للتو وسنقوم بهز الأشخاص الرئيسيين.
وما يمكننا فعله هو الاستعلام البسيط والاستعلام الموسع.
ما هو المميز في كل نهج؟
استعلام بسيط مفيد للتنفيذ لمرة واحدة. بمجرد القيام به ونسيانه. والمشكلة هي أنها لا تدعم تنسيق البيانات الثنائية، أي أنها غير مناسبة لبعض الأنظمة عالية الأداء.
الاستعلام الموسع - يتيح لك توفير الوقت في التحليل. وهذا ما فعلناه وبدأنا في استخدامه. لقد ساعدنا هذا حقًا. لا توجد وفورات فقط في التحليل. هناك وفورات في نقل البيانات. يعد نقل البيانات بتنسيق ثنائي أكثر كفاءة.
دعنا ننتقل إلى الممارسة. هذا ما يبدو عليه التطبيق النموذجي. يمكن أن يكون جافا، الخ.
أنشأنا البيان. نفذ الأمر. تم إنشاؤها بالقرب. أين الخطأ هنا؟ ما المشكلة؟ لا مشكلة. وهذا ما جاء في جميع الكتب. هذه هي الطريقة التي ينبغي أن تكون مكتوبة. إذا كنت تريد أقصى قدر من الأداء، فاكتب مثل هذا.
لكن الممارسة أظهرت أن هذا لا ينجح. لماذا؟ لأن لدينا طريقة "إغلاق". وعندما نفعل ذلك، من وجهة نظر قاعدة البيانات، يتبين أن الأمر يشبه عمل المدخن مع قاعدة بيانات. قلنا "تحليل تنفيذ إلغاء التخصيص".
لماذا كل هذا الإنشاء الإضافي وتفريغ البيانات؟ لا أحد يحتاج إليهم. ولكن ما يحدث عادة في PreparationStatements هو أنه عندما نغلقها، فإنها تغلق كل شيء في قاعدة البيانات. ليس هذا ما نريد.
نريد، مثل الأشخاص الأصحاء، أن نعمل مع القاعدة. لقد أخذنا بياننا وأعددناه مرة واحدة، ثم قمنا بتنفيذه عدة مرات. في الواقع، في كثير من الأحيان - وهذا مرة واحدة في عمر التطبيقات بالكامل - تم تحليلها. ونحن نستخدم نفس معرف البيان في RESTs المختلفة. هذا هو هدفنا.
كيف نستطيع إنجاز هذا؟
الأمر بسيط جدًا - لا داعي لإغلاق البيانات. نكتبها على النحو التالي: "التحضير" "التنفيذ".
إذا أطلقنا شيئًا كهذا، فمن الواضح أن شيئًا ما سوف يفيض في مكان ما. إذا لم يكن الأمر واضحًا، يمكنك تجربته. لنكتب معيارًا يستخدم هذه الطريقة البسيطة. إنشاء بيان. نقوم بتشغيله على بعض إصدارات برنامج التشغيل ونجد أنه يتعطل بسرعة كبيرة مع فقدان كل الذاكرة التي كانت لديه.
ومن الواضح أن مثل هذه الأخطاء يمكن تصحيحها بسهولة. لن أتحدث عنهم. لكنني سأقول أن الإصدار الجديد يعمل بشكل أسرع بكثير. الأسلوب غبي، ولكن لا يزال.
كيف تعمل بشكل صحيح؟ ماذا علينا أن نفعل لهذا؟
في الواقع، تقوم التطبيقات دائمًا بإغلاق البيانات. في كل الكتب يقولون أغلقوه وإلا ستتسرب الذاكرة.
ولا يعرف PostgreSQL كيفية تخزين الاستعلامات مؤقتًا. من الضروري أن تقوم كل جلسة بإنشاء ذاكرة التخزين المؤقت هذه لنفسها.
ولا نريد إضاعة الوقت في التحليل أيضًا.
وكالعادة لدينا خياران.
الخيار الأول هو أن نأخذه ونقول لنختتم كل شيء في PgSQL. هناك مخبأ هناك. إنه يخزن كل شيء. سوف يتحول إلى شيء عظيم. لقد رأينا هذا. لدينا 100500 طلب. لا يعمل. لا نوافق على تحويل الطلبات إلى إجراءات يدويًا. لا لا.
لدينا خيار ثانٍ - خذه واقطعه بأنفسنا. نفتح المصادر ونبدأ في القطع. لقد رأينا ورأينا. اتضح أن هذا ليس بالأمر الصعب.
ظهر هذا في أغسطس 2015. الآن هناك نسخة أكثر حداثة. وكل شيء عظيم. إنه يعمل بشكل جيد لدرجة أننا لا نغير أي شيء في التطبيق. وحتى أننا توقفنا عن التفكير في اتجاه PgSQL، أي كان هذا كافيًا بالنسبة لنا لتقليل جميع التكاليف العامة إلى الصفر تقريبًا.
وبناء على ذلك، يتم تنشيط البيانات المعدة من قبل الخادم عند التنفيذ الخامس لتجنب إهدار الذاكرة في قاعدة البيانات عند كل طلب لمرة واحدة.
قد تسأل – أين الأرقام؟ على ماذا تحصل؟ وهنا لن أعطي أرقاما، لأن كل طلب له خاصته.
كانت استفساراتنا من النوع الذي أمضينا حوالي 20 مللي ثانية في تحليل استعلامات OLTP. كان هناك 0,5 مللي ثانية للتنفيذ، و20 مللي ثانية للتحليل. الطلب – 10 كيلو بايت من النص، و170 سطرًا من الخطة. هذا طلب OLTP. يطلب 1، 5، 10 أسطر، وأحياناً أكثر.
لكننا لم نرغب في إضاعة 20 مللي ثانية على الإطلاق. لقد خفضناها إلى 0. كل شيئ عظيم.
ماذا يمكنك أن تأخذ بعيدا من هنا؟ إذا كان لديك Java، فأنت تأخذ الإصدار الحديث من برنامج التشغيل ونفرح.
إذا كنت تتحدث لغة أخرى، ففكر - ربما تحتاج إليها أيضًا؟ لأنه من وجهة نظر اللغة النهائية، على سبيل المثال، إذا كان لديك PL 8 أو LibPQ، فليس من الواضح بالنسبة لك أنك تقضي وقتًا ليس في التنفيذ، بل في التحليل، وهذا الأمر يستحق التحقق. كيف؟ كل شيء مجاني.
إلا أن هناك أخطاء وبعض الخصوصيات. وسنتحدث عنهم الآن. معظمها سيكون حول علم الآثار الصناعية، حول ما وجدناه، وما صادفناه.
إذا تم إنشاء الطلب بشكل حيوي. يحدث ذلك. يقوم شخص ما بلصق السلاسل معًا، مما يؤدي إلى استعلام SQL.
لماذا هو سيء؟ إنه أمر سيء لأنه في كل مرة ينتهي بنا الأمر بسلسلة مختلفة.
ويجب قراءة رمز التجزئة لهذه السلسلة المختلفة مرة أخرى. هذه حقًا مهمة وحدة المعالجة المركزية - العثور على نص طلب طويل حتى في التجزئة الموجودة ليس بالأمر السهل. ولذلك، فإن الاستنتاج بسيط - لا تولد الطلبات. تخزينها في متغير واحد. ونفرح.
المشكلة التالية. أنواع البيانات مهمة. هناك ORMs تقول أنه لا يهم أي نوع من NULL موجود، فليكن هناك نوعًا ما. إذا Int، فإننا نقول setInt. وإذا كان NULL، فليكن دائمًا VARCHAR. وما الفرق الذي يحدثه في النهاية ما هو NULL الموجود؟ قاعدة البيانات نفسها سوف تفهم كل شيء. وهذه الصورة لا تعمل.
ومن الناحية العملية، قاعدة البيانات لا تهتم على الإطلاق. إذا قلت في المرة الأولى أن هذا رقم، وفي المرة الثانية قلت إنه VARCHAR، فمن المستحيل إعادة استخدام البيانات المعدة من قبل الخادم. وفي هذه الحالة، علينا إعادة إنشاء العبارة.
إذا كنت تقوم بتنفيذ نفس الاستعلام، فتأكد من عدم الخلط بين أنواع البيانات الموجودة في العمود الخاص بك. أنت بحاجة إلى الحذر من NULL. هذا خطأ شائع حدث لدينا بعد أن بدأنا في استخدام PreparationStatements
حسنًا، تم التشغيل. ربما أخذوا السائق. وانخفضت الإنتاجية. أصبحت الأمور سيئة.
كيف يحدث هذا؟ هل هذا خلل أو ميزة؟ لسوء الحظ، لم يكن من الممكن فهم ما إذا كان هذا خطأ أم ميزة. ولكن هناك سيناريو بسيط للغاية لإعادة إنتاج هذه المشكلة. لقد نصبت لنا كمينًا بشكل غير متوقع. ويتكون من أخذ العينات حرفيا من جدول واحد. وبطبيعة الحال، كان لدينا المزيد من هذه الطلبات. كقاعدة عامة، قاموا بتضمين جدولين أو ثلاثة، ولكن هناك مثل هذا السيناريو للتشغيل. خذ أي إصدار من قاعدة البيانات الخاصة بك وقم بتشغيله.
النقطة المهمة هي أن لدينا عمودين، كل منهما مفهرس. يوجد مليون صف في عمود NULL واحد. والعمود الثاني يحتوي على 20 سطراً فقط. عندما ننفذ بدون متغيرات مرتبطة، كل شيء يعمل بشكل جيد.
إذا بدأنا التنفيذ باستخدام متغيرات مرتبطة، أي أننا ننفذ الأمر "؟" أو "$1" لطلبنا، ما الذي سنحصل عليه في النهاية؟
التنفيذ الأول كما هو متوقع. والثاني هو أسرع قليلا. تم تخزين شيء ما مؤقتًا. الثالث والرابع والخامس. ثم فرقعة - وشيء من هذا القبيل. والأسوأ من ذلك أن هذا يحدث في الإعدام السادس. من كان يعلم أنه كان من الضروري تنفيذ ستة عمليات إعدام بالضبط لفهم خطة التنفيذ الفعلية؟
من هو المذنب؟ ماذا حدث؟ تحتوي قاعدة البيانات على التحسين. ويبدو أنه الأمثل للحالة العامة. وبناء على ذلك، بدءا من مرحلة ما، تنتقل إلى خطة عامة، والتي، لسوء الحظ، قد تكون مختلفة. قد يكون هو نفسه، أو قد يكون مختلفا. وهناك نوع من القيمة العتبية التي تؤدي إلى هذا السلوك.
ماذا يمكنك أن تفعل بهذا الشأن؟ هنا، بالطبع، من الصعب افتراض أي شيء. هناك حل بسيط نستخدمه. هذا هو +0، الإزاحة 0. بالتأكيد أنت تعرف مثل هذه الحلول. نحن فقط نأخذها ونضيف "+0" إلى الطلب وكل شيء على ما يرام. سأريكم لاحقا.
وهناك خيار آخر - انظر إلى الخطط بعناية أكبر. يجب على المطور ألا يكتب طلبًا فحسب، بل يجب أن يقول أيضًا "شرح وتحليل" 6 مرات. إذا كان 5، فلن يعمل.
وهناك خيار ثالث - اكتب رسالة إلى قراصنة pgsql. كتبت، ومع ذلك، ليس من الواضح بعد ما إذا كان هذا خطأ أو ميزة.
بينما نفكر فيما إذا كان هذا خطأ أم ميزة، فلنصلحه. لنأخذ طلبنا ونضيف "+0". كل شيء على ما يرام. رمزان ولا يتعين عليك حتى التفكير في كيفية وجودهما أو ما هو عليه. بسيط جدا. لقد منعنا ببساطة قاعدة البيانات من استخدام فهرس في هذا العمود. ليس لدينا فهرس في العمود "+0"، وهذا كل شيء، قاعدة البيانات لا تستخدم الفهرس، كل شيء على ما يرام.
هذه هي القاعدة 6 شرح. الآن في الإصدارات الحالية عليك القيام بذلك 6 مرات إذا كان لديك متغيرات مرتبطة. إذا لم يكن لديك متغيرات مرتبطة، فهذا ما نفعله. وفي النهاية، هذا الطلب بالتحديد هو الذي فشل. إنه ليس بالأمر الصعب.
يبدو أن كم هو ممكن؟ خلل هنا، وخلل هناك. في الواقع، الخلل موجود في كل مكان.
دعونا نلقي نظرة فاحصة. على سبيل المثال، لدينا مخططين. المخطط أ مع الجدول S والمخطط B مع الجدول S. الاستعلام - تحديد البيانات من الجدول. ماذا سيكون لدينا في هذه الحالة؟ سيكون لدينا خطأ. سيكون لدينا كل ما سبق. القاعدة هي أن الخلل موجود في كل مكان، وسيكون لدينا كل ما سبق.
والسؤال الآن هو لماذا؟" يبدو أن هناك وثائق تشير إلى أنه إذا كان لدينا مخطط، فهناك متغير "search_path" يخبرنا بمكان البحث عن الجدول. ويبدو أن هناك متغير.
ما المشكلة؟ تكمن المشكلة في أن البيانات المعدة بواسطة الخادم لا تشك في إمكانية تغيير مسار البحث بواسطة شخص ما. تظل هذه القيمة ثابتة بالنسبة لقاعدة البيانات. وبعض الأجزاء قد لا تلتقط معاني جديدة.
بالطبع، هذا يعتمد على الإصدار الذي تختبره. يعتمد على مدى خطورة اختلاف جداولك. وسيقوم الإصدار 9.1 ببساطة بتنفيذ الاستعلامات القديمة. قد تكتشف الإصدارات الجديدة الخطأ وتخبرك بوجود خطأ ما.
كيفية التعامل معها؟ هناك وصفة بسيطة - لا تفعلها. ليست هناك حاجة لتغيير مسار البحث أثناء تشغيل التطبيق. إذا قمت بالتغيير، فمن الأفضل إنشاء اتصال جديد.
يمكنك المناقشة، أي فتح، ومناقشة، وإضافة. ربما يمكننا إقناع مطوري قواعد البيانات أنه عندما يقوم شخص ما بتغيير قيمة ما، يجب أن تخبر قاعدة البيانات العميل بهذا: "انظر، لقد تم تحديث القيمة الخاصة بك هنا. ربما تحتاج إلى إعادة ضبط البيانات وإعادة إنشائها؟" الآن تتصرف قاعدة البيانات سرًا ولا تبلغ بأي شكل من الأشكال عن تغير البيانات في مكان ما بالداخل.
وسأؤكد مرة أخرى - هذا شيء غير معتاد بالنسبة لجافا. سنرى نفس الشيء في PL/pgSQL واحدًا لواحد. ولكن سيتم إعادة إنتاجها هناك.
دعونا نجرب المزيد من اختيار البيانات. نحن نختار ونختار. لدينا جدول بمليون صف. كل سطر هو كيلو بايت. ما يقرب من غيغابايت من البيانات. ولدينا ذاكرة عاملة في جهاز جافا تبلغ سعتها 128 ميجابايت.
نحن، كما هو موصى به في جميع الكتب، نستخدم معالجة الدفق. أي أننا نفتح resultSet ونقرأ البيانات من هناك شيئًا فشيئًا. هل ستعمل؟ هل سيسقط من الذاكرة؟ هل ستقرأ قليلا؟ دعونا نثق في قاعدة البيانات، دعونا نثق في Postgres. نحن لا نصدق ذلك. هل سنسقط خارج الذاكرة؟ من شهد OutOfMemory؟ ومن تمكن من إصلاحه بعد ذلك؟ تمكن شخص ما من إصلاحه.
إذا كان لديك مليون صف، فلا يمكنك الانتقاء والاختيار فحسب. الإزاحة/الحد مطلوب. من هو لهذا الخيار؟ ومن يؤيد اللعب مع الالتزام التلقائي؟
هنا، كالعادة، الخيار الأكثر غير متوقع هو الصحيح. وإذا قمت بإيقاف تشغيل الالتزام التلقائي فجأة، فسوف يساعدك ذلك. لماذا هذا؟ العلم لا يعرف عن هذا.
ولكن بشكل افتراضي، يقوم جميع العملاء المتصلين بقاعدة بيانات Postgres بجلب البيانات بأكملها. PgJDBC ليس استثناءً في هذا الصدد؛ فهو يحدد جميع الصفوف.
هناك اختلاف في سمة FetchSize، أي يمكنك القول على مستوى بيان منفصل أنه هنا، يرجى تحديد البيانات بمقدار 10، 50. ولكن هذا لا يعمل حتى تقوم بإيقاف تشغيل الالتزام التلقائي. تم إيقاف تشغيل الالتزام التلقائي - يبدأ العمل.
لكن المرور عبر الكود وإعداد setFetchSize في كل مكان أمر غير مريح. لذلك، قمنا بإعداد الإعداد الذي سيحدد القيمة الافتراضية للاتصال بأكمله.
هذا ما قلناه. تم تكوين المعلمة. وماذا حصلنا عليه؟ إذا اخترنا مبالغ صغيرة، على سبيل المثال، إذا اخترنا 10 صفوف في المرة الواحدة، فلدينا تكاليف عامة كبيرة جدًا. ولذلك، ينبغي تعيين هذه القيمة إلى حوالي مائة.
من الناحية المثالية، بالطبع، لا يزال يتعين عليك تعلم كيفية تحديدها بالبايت، ولكن الوصفة هي كما يلي: اضبط defaultRowFetchSize على أكثر من مائة وكن سعيدًا.
دعنا ننتقل إلى إدخال البيانات. الإدراج أسهل، وهناك خيارات مختلفة. على سبيل المثال، إدراج، قيم. هذا خيار جيد. يمكنك أن تقول "إدراج تحديد". في الممارسة العملية هو نفس الشيء. لا يوجد فرق في الأداء.
تقول الكتب أنك بحاجة إلى تنفيذ عبارة Batch، وتقول الكتب أنه يمكنك تنفيذ أوامر أكثر تعقيدًا باستخدام عدة أقواس. ولدى Postgres ميزة رائعة - يمكنك إجراء النسخ، أي القيام بذلك بشكل أسرع.
إذا قمت بقياسه، يمكنك مرة أخرى إجراء بعض الاكتشافات المثيرة للاهتمام. كيف نريد أن يعمل هذا؟ نريد عدم التحليل وعدم تنفيذ الأوامر غير الضرورية.
من الناحية العملية، لا يسمح لنا بروتوكول TCP بالقيام بذلك. إذا كان العميل مشغولاً بإرسال طلب، فإن قاعدة البيانات لا تقرأ الطلبات في محاولات إرسال الردود إلينا. والنتيجة النهائية هي أن العميل ينتظر قاعدة البيانات لقراءة الطلب، وقاعدة البيانات تنتظر العميل لقراءة الاستجابة.
وبالتالي يضطر العميل إلى إرسال حزمة المزامنة بشكل دوري. تفاعلات الشبكة الإضافية، مضيعة للوقت.
وكلما أضفناها أكثر، أصبح الأمر أسوأ. السائق متشائم تمامًا ويضيفها كثيرًا، مرة واحدة تقريبًا كل 200 سطر، اعتمادًا على حجم الخطوط، وما إلى ذلك.
يحدث أنك قمت بتصحيح سطر واحد فقط وسيتسارع كل شيء 10 مرات. يحدث ذلك. لماذا؟ كالعادة، تم بالفعل استخدام ثابت مثل هذا في مكان ما. والقيمة "128" تعني عدم استخدام الخلط.
من الجيد أن هذا لم يتم تضمينه في الرواية الرسمية. تم اكتشافه قبل بدء الإصدار. كل المعاني التي أعطيها مبنية على الإصدارات الحديثة.
دعونا نحاول ذلك. نحن نقيس InsertBatch بشكل بسيط. نقوم بقياس InsertBatch عدة مرات، أي نفس الشيء، ولكن هناك العديد من القيم. خطوة صعبة. لا يستطيع الجميع القيام بذلك، لكنها خطوة بسيطة، وأسهل بكثير من COPY.
يمكنك عمل نسخة.
ويمكنك القيام بذلك على الهياكل. قم بتعريف النوع الافتراضي للمستخدم، وقم بتمرير المصفوفة وإدراجها مباشرةً في الجدول.
إذا قمت بفتح الرابط: pgjdbc/ubenchmsrk/InsertBatch.java، فهذا الرمز موجود على GitHub. يمكنك أن ترى على وجه التحديد ما هي الطلبات التي يتم إنشاؤها هناك. لا يهم.
أطلقنا. وأول شيء أدركناه هو أن عدم استخدام الدُفعات أمر مستحيل بكل بساطة. جميع خيارات الدفع هي صفر، أي أن وقت التنفيذ هو صفر تقريبًا مقارنة بالتنفيذ لمرة واحدة.
نقوم بإدخال البيانات. إنها طاولة بسيطة للغاية. ثلاثة أعمدة. وماذا نرى هنا؟ نرى أن هذه الخيارات الثلاثة قابلة للمقارنة تقريبًا. والنسخة أفضل بالطبع.
هذا عندما نقوم بإدخال القطع. عندما قلنا أن هناك قيمة واحدة، أو قيمتين، أو ثلاث قيم، أو أشرنا إلى 10 منها مفصولة بفاصلة. هذا مجرد أفقي الآن. 1، 2، 4، 128. يمكن ملاحظة أن ملحق الدفعة، المرسوم باللون الأزرق، يجعله يشعر بتحسن كبير. وهذا يعني أنه عندما تقوم بإدراج واحدة في كل مرة أو حتى عندما تقوم بإدراج أربعة في المرة الواحدة، فإنها تصبح أفضل مرتين، وذلك ببساطة لأننا حشرنا المزيد في القيم. تنفيذ عمليات أقل.
يعد استخدام COPY بكميات صغيرة أمرًا غير واعد على الإطلاق. ولم أرسم حتى على الأولين. يذهبون إلى الجنة، أي هذه الأرقام الخضراء للنسخ.
يجب استخدام COPY عندما يكون لديك ما لا يقل عن مائة صف من البيانات. الحمل لفتح هذا الاتصال كبير. وبصراحة، لم أحفر في هذا الاتجاه. أنا الأمثل دفعة، ولكن ليس نسخة.
ما التالي؟ لقد جربناها. نحن نفهم أننا بحاجة إلى استخدام أي من الهياكل أو البكال الذكي الذي يجمع بين عدة معانٍ.
ما الذي يجب عليك استخلاصه من تقرير اليوم؟
- ReadyStatement هو كل شيء لدينا. وهذا يعطي الكثير للإنتاجية. وينتج تخبط كبير في المرهم.
- وعليك أن تقوم بالتحليل الشرح 6 مرات.
- ونحن بحاجة إلى تخفيف OFFSET 0، والحيل مثل +0 لتصحيح النسبة المتبقية من استفساراتنا الإشكالية.
المصدر: www.habr.com