Improving SQL Queries Performance Tips & Tricks

بنحتك بشكل كبير بقواعد البيانات ، وأصبح من المهم دلوقتي أن يكون عندنا مهارة قوية في التعامل مع الـ SQL ونكون فاهمين كويس ازاي نكتب Queries تكون قوية و Efficient
Improving SQL Queries Performance Tips & Tricks
Improving SQL Queries Performance Tips & Tricks

في هذه الصفحة

المقدمة

بنسبة كبيرة في أغلب شغلنا كـ Backend Developers بنحتك بشكل كبير بقواعد البيانات ، وأصبح من المهم دلوقتي أن يكون عندنا مهارة قوية في التعامل مع الـ SQL ونكون فاهمين كويس ازاي نكتب Queries تكون قوية و Efficient عشان مندفعش ضريبتها في الـ Performance بتاع التطبيق اللي بنبنيه.

فتعالوا نشوف مع بعض بعض النصايح والـ Tips and Tricks اللي ممكن نستعملهم عشان نحسن من الـ SQL Query Performance.


SELECT *

من الشائع واللي أغلبنا اتعلمناه واحنا بندرس قواعد بيانات واللي بقينا بنستعمله بشكل كبير عشان بيسهل الدنيا علينا هي اننا نروح نعمل الـ SQL Query دي :

SELECT * FROM students;

المشكلة هنا ، ان بنسبة كبيرة جدًا أغلب اللي بنكون محتاجينه وقتها مش كل الـ Columns اللي موجودين في الـ Students Table ولكن بنكون محتاجين Columns محددة زي الاسم والعمر ، او ايا يكن .. ولكن مش كل البيانات!

فالـ SELECT * للأسف بتؤدي لمشاكل في الـ Performance خصوصا مع حجم البيانات المتزايد واللي هيكون موجود ولان ده من ورا بيتطلب ان يتعمل عشان يتنفذ Full Table Scan كـ Query Execution Plan.

طب الأفضل اعمل ايه ؟

الأفضل انك تختار وتحدد الـ Columns اللي انت محتاجها فقط لا غير زي كده :

SELECT student_id, name, email FROM students;

SELECT DISTNICT

كلنا اتعلمنا في بداية حياتنا ان عشان نرجع الـ Data وتكون Unique يعني مش مكررة ، بنستعمل DISTINCT ولكن للأسف اللي ما نعرفوش اننا بالشكل ده بنسبب مشكلة كبيرة في الـ Performance طب ليه ؟

لما بنيجي نستعمل جملة SQL Query زي الشكل ده :

SELECT DISTINCT city FROM students;

العملية دي بتكون مكلفة جدًا وده لإن من ورا واللي انت مش عارفه ان بيتم مقارنة كل Row مع الـ Rows التانية ، ومش بس كده ده الموضوع بيتطلب عمل Sorting / Filtering واللي بالطبع هيكون مكلف خصوصا في الـ Tables اللي فيها كميات كبيرة من البيانات.

فالأفضل دايمًا لو محتاجين اننا نـ Query Unique Data , اننا نعتمد على الـ Design زي ان يكون عندنا Primary Keys أو بعض الـ Unique Constraints اللي محطوطة.

وكحل بديل ممكن نستعمل الـ GROUP BY بالشكل الآتي :

SELECT city FROM students GROUP BY city;

فالـ GROUB BY هتكون مفيدة جدًا خصوصًا مع استعمال Indexing بشكل كويس.


Indexing

اتكلمنا قبل كده في اكتر من مقال عن الـ Indexes في قواعد البيانات وكمان كنا عملنا عنه ورقة وقلم وشرحناه بشكل مبسط تقدروا تشوفوه من هنا :

Database Indexing
ال database indexing من أهم مفاهيم قواعد البيانات اللي بنتعامل معاها يوميًا وبتساعدنا نسرع عملية طلب البيانات فورقة وقلم وتعالوا نتعرف أكثر عليه.

Database Indexing

ولكن كمراجعة للموضوع ، الـ Indexing من الحاجات المؤثرة والحيوية في أداء الـ SQL Queries ، وده لإنه بيسرع من طريقة إيجاد الـ Rows المطلوبة ، بدلا ما نروح نعدي ونعمل Full Table Scan على كل العناصر اللي موجودة في الـ Table.

وده مثال واحنا بنبني Index مثلًا على الـ City Column في الـ Student Table.

CREATE INDEX idx_student_city ON students(city);

وكنا اتكلمنا قبل كده في مقال مفصل عن ازاي الـ Indexes والـ Types بتاعتها المختلفة بتأثر بشكل كبير وملحوظ مع الكميات الكبيرة من البيانات تقدروا تشوفوه من هنا :

Indexing - Query Plan and Performance Optimisation
الـ Index هو عبارة عن Data Structure الـ DBMS تعتمد عليه لتحسن من اداء الـ Query Plan التي ستنفذها عند تشغيل الـ Query التي ارسلتها إليها .. وينقسم إلى نوعين رئيسين يندرج تحتهم انواع فرعيةأخرى

Indexing - Query Plan and Performance Optimisation

ومع الـ Execution Time واننا نعمل Explain للـ Queries دي نقدر نشوف مدى التأثير اللي هيحصل قبل وبعد الـ Index ونشوف بعنينا ازاي ده بيساعد في تحسين الـ Performance.

وخلونا نوضح لمرة تانية هي ان على قد مالـ Index مفيد جدًا , وانه بيساعد في تحسين أداء الـ SQL Queries خصوصًا اللي بتكون محتاجة يتعمل عليها Filter على Indexed Columns ، ولكن اننا نـ Create منهم بشكل كتير ده هيكون ليه ضريبة عكسية وضرر أكبر من النفع.

وده لإن عمليات الكتابة هتتأثر بشكل كبير بالموضوع ده خصوصا عمليات الـ Update , Delete , Insert وده لإن الـ Index محتاج يتعمله Update بعد كل عملية من دول وبالتالي هيكون مكلف .. وعشان كده هنلاقي ان العمليات اللي قولنا عليها دي كلها هتبقى بطيئة وهيبقى الـ Performance بتاعها سيء جدًا مع وجود Indexes عمال على بطال بدون دراية ودراسة كويسة.


Limit Query Result

خلاص عرفنا اننا هنبطل نستعمل SELECT * هيجي حد دلوقتي يقولي خلاص اذن بعد كده هروح اعمل:

SELECT student_id, name, email FROM students;

نقوله هنا دي برضو هتسبب مشكلة كبيرة خصوصا مع الـ Tables اللي فيها عدد كبير من البيانات .. طب ليه ؟

وده لإن لو الـ Table ده فيه 1,000,000 طالب ، فانت بتقول لقاعدة البيانات تجبلك بيانات الـ 1,000,000 مرة واحدة ، وده مش حل Efficient لان مفيش حد هيكون مهتم ببيانات الـ 1,000,000 مرة واحدة.

فالأفضل انك تـ Limit العدد اللي هيرجعلك من الـ Query ده وليكن مثلا تقول هاتلي 10 أو 20 , ولو عوزت 20 تانيين ترجع 20 تانيين وهكذا. ده هيكون أسرع كتير في تقليل عدد البيانات اللي مفروض انها ترجع ويتعملها معالجة، وهيكون أفضل من انك تروح ترجع بيانات الـ 1,000,000 كلهم مرة واحدة.

SELECT student_id, name, email FROM students LIMIT 20;

في الختام

تحسين أداء الـ SQL Queries بيتضمن معرفة بالبيانات الموجودة , والبيانات اللي محتاجينها , واننا نكون فاهمين كويس ازاي الـ SQL Queries بتتصرف من خلال الـ SQL Query Execution Plan عشان نقدر نحدد انسب طريقة لتحسين الـ Queries.

احنا اتكلمنا عن بعض الـ Tips and Tricks لتحسين من بعض الـ SQL Queries ، ولكن مما لا شك فيه ان فيه برضو Techniques تانية كتير ممكن تكون مفيدة!

اشترك الآن بنشرة اقرأ-تِك الأسبوعية

لا تدع أي شيء يفوتك. واحصل على أحدث المقالات المميزة مباشرة إلى بريدك الإلكتروني وبشكل مجاني!