12 روش برای بهینه سازی کوئری های SQL برای دیتابیس

برنامه های کاربردی پایگاه داده (دیتابیس) به یکی از اجزای حیاتی بسیاری از شرکت ها در دنیای داده محور امروزی تبدیل شده اند. با توجه به انتخاب بسیاری از شرکت‌ها برای پردازش و ذخیره داده‌های خود در فضای ابری، بهینه‌سازی کوئری ها بیش از هر زمان دیگری برای خط نهایی یک شرکت مهم شده است.

ما در این مقاله چند تکنیک موثر برای تسریع عملکرد کوئری SQL را بررسی خواهیم کرد. راه های مختلفی برای بهینه سازی کوئری های SQL برای عملکرد سریعتر وجود دارد که در زیر مورد بحث قرار گرفته است.

1. از ایندکس ها به طور موثر در پایگاه های داده رابطه ای

در پایگاه های رابطه ای MySQL و Postgres باید از ایندکس ها به صورت موثر استفاده کرد.من دوست دارم ایندکس ها را به عنوان کلیدهای اصلی(primary keys) و جداول نگاشت در SQL در نظر بگیرم. در جداول داده گسترده، اغلب کدهای شناسایی یا اعداد صحیح را می بینید که به جدول داده دیگری نگاشت می شوند. این یک روش موثر برای ذخیره سازی داده ها است زیرا به شما امکان می دهد به راحتی جدول گسترده را جستجو کنید و مقادیر را به جدول دیگری بپیوندید. اساساً، این کار جزئیات بیشتری را در مورد یک ردیف داده ارائه می دهد. همچنین ایندکس هایی را در قالب کلیدهای اصلی می بینید که به شما امکان می دهد یک ردیف منحصر به فرد را انتخاب کنید.

این دو روش indexing به شما کمک می کند تا داده ها را سریعتر در جداول قرار دهید. از آنجایی که ایندکس ها داده ها را در یک یا چند ستون ذخیره می کنند، می توانید به راحتی یک مقدار یا حتی محدوده ای از مقادیر را پیدا کنید. به عنوان مثال، اگر از یک عبارت WHERE در یک کوئری استفاده کنید، یک ایندکس از اسکن کل جدول جلوگیری می کند. در عوض، می‌توانید به سادگی به دنبال یک شرط مطابقت باشید. اگر اغلب این نوع کوئری ها را انجام می‌دهید، این باعث صرفه‌جویی در وقت شما می‌شود.

به خاطر داشته باشید که انبارهای داده ابری مانند Redshift و Snowflake ستونی هستند و ایندکس هایی مانند پایگاه داده های رابطه ای ندارند. آنها به طور خودکار داده ها را بر اساس توزیع داده ها در طول زمان بارگذاری پارتیشن بندی می کنند. در اینجا، من توصیه می‌کنم داده‌ها را به ترتیب مرتب‌سازی شده بارگیری کنید که اغلب آن را کوئری می‌کنید.

شما همچنین می توانید پارتیشن را لغو کنید، و باعث می شود پایگاه داده مجدداً جمع شده و داده ها را بر اساس آن توزیع کند.

سه نوع ایندکس اصلی وجود دارد:
 

ایندکس های خوشه ای

ایندکس های خوشه ای به صورت فیزیکی ستون ها را بر اساس مقدار واقعی آنها مرتب می کنند.

شما فقط زمانی می خواهید از ایندکس های خوشه ای استفاده کنید که مقادیر ستون شما به ترتیب یا مرتب شده باشد و مقادیر تکراری وجود نداشته باشد. این به این دلیل است که ایندکس آنها را بر اساس مقدار واقعی در خود ستون مرتب می کند. هنگامی که این ایندکس ایجاد شد، سپس به ردیفی که حاوی داده است اشاره می کند، نه خود داده. کلیدهای اولیه شکلی از ایندکس های خوشه ای هستند.

ایندکس های غیر خوشه ای

ایندکس های غیر خوشه ای دو ستون مجزا ایجاد می کنند، یکی برای ایندکس و دیگری که به مقدار اشاره می کند. این نوع ایندکس معمولاً برای نگاشت جداول یا حتی هر نوع واژه نامه استفاده می شود. شما مقادیر ستون خاصی دارید که به یک مکان خاص اشاره می کند. بر خلاف ایندکس های خوشه ای، ایندکس مستقیماً به داده ها اشاره می کند.

اگر بین این دو ایندکس انتخاب می‌کنید، ایندکس‌های خوشه‌ای راهی برای رفتن هستند. آنها سریعتر هستند و برای اجرا به حافظه کمتری نیاز دارند زیرا در دو مکان جداگانه وجود ندارند. این تمرین عملکرد انبار داده ابری شما را بهینه می کند.

ایندکس‌های Full-text

ایندکس‌های تمام متنی نیز وجود دارند که نادرتر هستند، اما به شما امکان می‌دهند در ستون‌هایی با متن زیاد جستجو کنید، مانند آنهایی که محتوای مقاله یا ایمیل را در خود جای می‌دهند. این نوع ایندکس‌ موقعیت عبارات موجود در فیلد ایندکس‌ شده را ذخیره می کند و یافتن آن را بسیار آسان می کند.

2. از * SELECT اجتناب کنید

باور کنید یا نه، هنگام کاوش مجموعه داده های مختلف در دیتابیس خود، نمی خواهید از * SELECT استفاده کنید. این نوع کوئری ها در واقع کاملاً ناکارآمد هستند، زیرا شما ترجیح می‌دهید همه فیلدها را در یک مجموعه داده مشاهده کنید نه فقط مواردی که به آنها نیاز دارید.

هنگام نوشتن کوئری های خود در یک مدل داده، حتماً ستون‌هایی را که هرگز توسط تحلیلگران داده یا کاربران تجاری استفاده نمی‌شوند، کنار بگذارید. اگر برای اهداف گزارش کوئری  می نویسید، فقط ستون هایی را که کاربران کسب و کار می خواهند به آنها نگاه کنند، اضافه کنید. هنگام کار برای جلوگیری از سردرگمی و بهینه سازی زمان اجرا، همیشه کمتر بهتر است!

انتخاب فقط فیلدهای خاصی که می‌خواهید یا باید مشاهده کنید، مدل‌ها و گزارش‌های شما را تمیز نگه می‌دارد و به راحتی قابل پیمایش است. در اینجا نمونه ای از آنچه می تواند شبیه باشد آورده شده است:

SELECT * FROM customers.customer_profiles → 
SELECT customer_name, customer_email, customer_phone FROM customers.customer_profiles

3. عملیات JOIN را بهینه کنید

Join ها می توانند کوئری های پیچیده را ایجاد یا شکست دهند. ضروری است که تفاوت بین inner join, outer join, left join, و right join را بدانید. استفاده از اتصال اشتباه می تواند در مجموعه داده های شما موارد تکراری ایجاد کند و سرعت آن را به شدت کاهش دهد.

outer join

توصیه می‌کنم فقط اگر مورد استفاده خاصی دارید که غیر از این قابل حل نیست، از outer join استفاده کنید. outer join، ردیف های منطبق و بی همتا را از هر دو جدولی که به آنها ملحق می شوید، برمی گرداند. اساساً همه چیز را از هر دو مجموعه داده در یک مجموعه داده برمی گرداند، که به نظر من اساساً هدف یک پیوستن را شکست می دهد. outer join تعداد زیادی تکراری تولید می‌کنند و داده‌هایی را که احتمالاً به آن نیاز ندارید برمی‌گردانند، که باعث ناکارآمدی آن‌ها می‌شود.

inner join

inner join فقط رکوردهای منطبق را از دو جدولی که شما به آنها ملحق می شوید برمی گرداند. این تقریباً همیشه بر outer join ترجیح داده می شود.

Left and right joins

Left و right joins همه رکوردها را از یک جدول و فقط رکوردهای منطبق از جدول در حال پیوست را برمی گرداند. برای اتصالات سمت چپ، کوئری به دست آمده شامل تمام مقادیر در جدول اول و فقط جداول منطبق در جدول دوم خواهد بود. برای اتصال سمت راست، برعکس است، کوئری به دست آمده شامل تمام مقادیر جدول دوم و فقط رکوردهای منطبق از جدول اول است.

من توصیه می کنم همیشه یک left join را به سمت راست انتخاب کنید. برای اینکه این کار را انجام دهید، به سادگی ترتیب پیوستن به جداول خود را تغییر دهید. خواندن و درک اتصال‌های چپ در مقایسه با اتصال‌های راست بسیار آسان‌تر است، که این نوع اتصال را برای حاکمیت داده، قابلیت اطمینان و کیفیت داده بهتر می‌کند.

در نهایت، با اتصال، مطمئن شوید که دو جدول را در یک فیلد مشترک به هم می‌پیوندید. اگر فیلدی را انتخاب می کنید که برای پیوستن به جداول وجود ندارد، ممکن است یک کوئری  بسیار طولانی دریافت کنید که در نهایت باعث اتلاف وقت و پول شما می شود. توصیه می‌کنم تأیید کنید که اتصال‌ها از کلیدهای اصلی و خارجی استفاده می‌کنند که بین دو جدول وجود دارد.

در اینجا نمونه ای از left join آورده شده است:

SELECT 
Profile.customer_name, 
Profile.customer_email, 
Address.home_state 
FROM customers.customer_profiles profile
LEFT JOIN customers.customer_addresses address
ON profile.customer_id = addresses.customer_id

همچنین، در صورت لزوم از پیوستن به بیش از یک ستون نترسید. گاهی اوقات این می تواند به کاهش تکرارهای حاصل و افزایش سرعت اجرا در مورد چندین رکورد با یک فیلد پیوسته کمک کند.

در اینجا یک مثال با اتصال داخلی آورده شده است:

SELECT 
  Customer_orders.customer_id, 
Order_details.order_id, 
Order_details.order_date  
FROM customers.customer_orders customer_orders
INNER JOIN orders.order_details order_details
ON customer_orders.customer_id = order_details.customer_id 
AND customer_orders.customer_order_id = order_details.order_id

4. استفاده از subqueries را به حداقل برسانید

خواندن و درک کوئری های فرعی برای هر کسی بسیار سخت است. به جای استفاده از کوئری های فرعی، به ویژه در مدل های پیچیده یا گزارش، به جای آن، CTE را انتخاب کنید. CTE مخفف عبارت جدول مشترک (common table expression) است و کد شما را به جای یک کوئری بزرگ به چند کوئری کوچک تر جدا می کند.

CTE ها درک آن را برای هر کسی که کد شما را می خواند آسان می کند. به عنوان یک امتیاز اضافی، فرآیند اشکال زدایی را نیز ساده می کند. به جای این که مجبور باشید هر زیرکوئری را در کوئری خود بیرون بکشید و در هر مرحله اشکال زدایی کنید، می توانید به سادگی از هر CTE انتخاب کنید و در حین حرکت اعتبار سنجی کنید.

در اینجا یک مثال است:

SELECT MAX(customer_signup) AS most_recent_signup 
FROM (SELECT customer_name, customer_phone, customer_signup FROM customer_details WHERE YEAR(customer_signup)=2023)
→ 
WITH 
2023_signups AS (
SELECT 
    customer_name, 
customer_phone, 
customer_signup 
FROM customer_details 
WHERE YEAR(customer_signup)=2023
), 
Most_recent_signup AS (
SELECT 
MAX(customer_signup) AS most_recent_signup 
FROM 2023_signups 
) 
SELECT most_recent_signup FROM Most_recent_signup

همانطور که می بینید، CTE کمی طولانی تر است، اما درک آن بسیار ساده تر است. اکنون، هر بازبینی کننده ای می تواند هر قطعه کوچکتر کوئری را تجزیه و تحلیل کند و به راحتی هر جزء را به یکدیگر مرتبط کند.

5. از بازیابی اطلاعات اضافی یا غیر ضروری خودداری کنید

هنگام کاوش مجموعه داده‌ها، توسعه گزارش‌ها یا مدل‌ها، و اعتبارسنجی داده‌ها، مهم است که فقط داده‌های مورد نیاز خود را بازیابی کنید. به این ترتیب شما پول خرج نمی کنید یا از منابع محاسباتی برای داده هایی که نیاز ندارید استفاده نمی کنید. همانطور که قبلا ذکر کردیم، مهم است که فقط ستون های لازم را به جای* SELECT انتخاب کنید. با این حال، محدود کردن تعداد ردیف‌هایی که برمی‌گردانید، نه فقط ستون‌ها، نیز مهم است. با پایگاه داده های رابطه ای مانند MySQL و Postgres، زمانی که تعداد ردیف ها افزایش می یابد، سرعت آنها کاهش می یابد.

می توانید از LIMIT برای کاهش تعداد ردیف های برگشتی استفاده کنید. معمولاً می بینید که ویرایشگرهای SQL مانند dbeaver یک ویژگی را برای محدود کردن بازگشت داده به 100 یا 200 تنظیم می کنند. این ویژگی داخلی مانع از برگرداندن ندانسته هزاران ردیف از داده ها می شود که فقط می خواهید به تعدادی از آنها نگاه کنید.

این توابع به ویژه برای کوئری های اعتبارسنجی یا مشاهده خروجی حاصل از تبدیلی که روی آن کار می کردید مفید هستند. آنها برای آزمایش و یادگیری بیشتر در مورد نحوه عملکرد کد شما خوب هستند. با این حال، این نوع توابع برای استفاده در مدل‌های داده خودکار که می‌خواهید همه داده‌ها را برگردانید خوب نیستند.

برای استفاده از LIMIT:

SELECT customer_name FROM customer_details ORDER BY customer_signup DESC LIMIT 100;

این فقط 100 ردیف را برمی گرداند، حتی اگر بیش از 100 customer داشته باشید.

همچنین اگر نمی‌خواهید 100 ردیف اول را برگردانید، اما می‌خواهید ابتدا برخی از آن‌ها را رد کنید، می‌توانید یک عبارت OFFSET را به توابع LIMIT خود اضافه کنید. اگر می‌خواهید 20 ردیف اول را نادیده بگیرید و بعد از آن 100 customer را انتخاب کنید، می‌نویسید:

SELECT customer_name FROM customer_details ORDER BY customer_signup DESC LIMIT 100 OFFSET 20;

در حالی که این کوئری ها به محدود کردن داده‌ها کمک می‌کنند، پلتفرم‌های داده‌های ابری نیز با استفاده از حافظه پنهان به کاهش تأثیر کوئری‌های اضافی کمک می‌کنند. همچنین می‌توانید از جداول موقت در پلتفرم‌های ابری برای ذخیره کوئری های تکراری استفاده کنید، فقط به یاد داشته باشید که پس از پایان استفاده از آنها، آنها را حذف کنید!

6. از رویه های ذخیره شده استفاده کنید

رویه های ذخیره شده (Stored procedures) اشیای پایگاه داده ای هستند که حاوی خطوط کد SQL هستند. آنها را می توان به منظور سرعت بخشیدن به زمان توسعه و ساده سازی منطق مورد استفاده مجدد و خودکار قرار داد. شما می توانید آنها را به عنوان "توابع" در نظر بگیرید، مانند آنهایی که در پی اچ پی و جاوا اسکریپت وجود دارند، که می توانند در محیط کد شما ذخیره و اعمال شوند.

رویه‌های ذخیره‌شده عملکرد را در پایگاه داده ابری شما بهبود می‌بخشند، زیرا آنها کد را کامپایل و ذخیره می‌کنند و امکان افزایش سرعت با کوئری های پرکاربرد را فراهم می‌کنند. آنها همچنین بسیاری از فرآیندها را برای توسعه دهندگان با وجود به عنوان یک قطعه کد قابل استفاده مجدد ساده می کنند. برنامه نویسان مجبور نیستند نگران نوشتن یک کد یکسان باشند. در عوض، آنها می توانند از توابع SQL که قبلاً در قالب یک رویه ذخیره شده وجود دارد، استفاده کنند.

شما می توانید یک رویه ذخیره شده مانند این ایجاد کنید:

CREATE PROCEDURE find_most_recent_customer
AS BEGIN 
SELECT 
MAX(customer_signup) AS most_recent_signup 
FROM 2023_signups 
END 

سپس با استفاده از دستور زیر می توانید این روال را اجرا کنید:

EXEC  find_most_recent_customer; 

همچنین می توانید با تعیین نام ستون و نوع داده، پارامترها را به رویه های ذخیره شده ارسال کنید.

CREATE PROCEDURE find_most_recent_customer
@store_id INT AS BEGIN 
SELECT 
MAX(customer_signup) AS most_recent_signup 
FROM 2023_signups 
WHERE store_id= @store_id 
END 

به سادگی ستون name_ را که قرار است پارامتر باشد با استفاده از علامت @ و نوع داده ای که می خواهید از آن ارسال شود، وارد کنید. سپس برای اجرای آن مجدداً پارامتر و مقدار آن را مشخص می کنید.

EXEC  find_most_recent_customer @store_id=1188; 

7. پارتیشن بندی و اشتراک گذاری برای MySQL و Postgres

پارتیشن بندی و اشتراک گذاری دو تکنیکی هستند که می توانید برای گسترش توزیع داده ها در فضای ابری استفاده کنید.

با پارتیشن بندی، یک جدول بزرگ را به چندین جدول کوچک تر تقسیم می کنید که هر کدام کلید پارتیشن خاص خود را دارند. کلیدهای پارتیشن معمولاً بر اساس زمان ایجاد سطرها یا حتی مقادیر صحیح آنها هستند. هنگامی که یک کوئری را در این جدول اجرا می کنید، سرور به طور خودکار شما را به جدول پارتیشن بندی شده مناسب برای درخواست شما هدایت می کند. این عملکرد را بهبود می بخشد زیرا به جای جستجوی کل جدول، فقط بخش کوچکی از آن را جستجو می کند.

Sharding کاملاً مشابه است به جز اینکه به جای تقسیم یک جدول بزرگ به جداول کوچک تر، یک پایگاه داده بزرگ را به پایگاه داده های کوچکتر تقسیم می کند. هر کدام از این پایگاه‌های اطلاعاتی روی سرور متفاوتی قرار دارند. به جای یک کلید پارتیشن، یک کلید اشتراک گذاری وجود دارد که کوئری ها را برای اجرا در پایگاه داده مناسب هدایت می کند.

Sharding به افزایش سرعت پردازش معروف است زیرا بار در سرورهای مختلف تقسیم می شود، هر دو به طور همزمان کار می کنند. همچنین پایگاه داده ها را به دلیل اینکه کاملاً مستقل از یکدیگر هستند در دسترس و قابل اعتمادتر می کند. اگر یک پایگاه داده از کار بیفتد، روی پایگاه داده های دیگر تأثیری نمی گذارد.

به خاطر داشته باشید که پلتفرم‌های داده ابری مدرن زمانی که کلید پارتیشن و نوع توزیع را در بارگذاری تعریف می‌کنید، این کار را به‌طور خودکار انجام می‌دهند. AWS همچنین یک محصول پایگاه داده رابطه ای به نام Aurora ارائه می دهد که پارتیشن بندی و اشتراک گذاری را خودکار می کند.

8. عادی سازی جداول پایگاه داده
فرض عادی سازی این است که مطمئن شوید مقادیر موجود در جداول پایگاه داده شما به راحتی قابل یافتن و جستجو هستند. عادی سازی در نزدیک ترین لایه به داده های خام شما مهم است تا بتوانید به راحتی مقادیر پایین دست را جستجو کنید.

اولین فرم عادی (1NF)

من اغلب با اشیاء JSON در داده های خام خود به مشکل برخورد می کنم. تجزیه این اشیاء JSON نوعی عادی سازی است که تضمین می کند هیچ شی تودرتو در داده های شما وجود ندارد. این در واقع اولین فرم طبیعی (1NF) نامیده می شود. با این شکل نرمال سازی، مقادیر باید به صورت مقادیر اتمی (مقداری که نمی توانند به مقادیر کوچکتر تقسیم شوند) وجود داشته باشند و هر ردیف باید یک کلید اصلی داشته باشد.

فرم دوم عادی (2NF)

دومین فرم عادی (2NF) نوع متفاوتی از نرمال سازی است که نیاز دارد فیلدهایی با مقادیر متعدد به ردیف های خود تقسیم شوند. این به شما امکان می دهد به راحتی به هر مقدار ذخیره شده در یک فیلد دسترسی داشته باشید زیرا اکنون وابسته به کلید اصلی اما در یک ردیف متفاوت وجود دارد.

فرم سوم عادی (3NF)

فرم عادی سوم (3NF) نوع دیگری از نرمال سازی است. فرم عادی دوم در واقع پیش نیاز این نوع عادی سازی است. بنابراین، در صورت استفاده از این فرم، مطمئن شوید که ابتدا مراحل 2NF را دنبال کرده اید. سپس، می‌خواهید به جدول خود نگاه کنید و ببینید آیا مقادیر ستون‌ها به یکدیگر وابسته هستند یا خیر. به عنوان مثال، اگر یک جدول مشتریان با نام مشتری، شماره تلفن، شهر و کد پستی دارید، کد پستی به شهر بستگی دارد. می توانید این مقادیر را به جدول دیگری تقسیم کنید. کد پستی و وضعیت در جدول خود وجود دارد در حالی که نام مشتری، شماره تلفن و وضعیت در جدول دیگر وجود دارد.

در حالی که فرم چهارم عادی و پنجمین فرم نرمال نیز وجود دارد، این تکنیک های نرمال سازی کمتر محبوب هستند و برای محدوده این مقاله مورد نیاز نیستند.

9. عملکرد کوئری

هنگام تلاش برای بهینه سازی کوئری های SQL، نظارت بر عملکرد کوئری کلیدی است. اگر هرگز به زمان اجرای کوئری های خود نگاه نکنید، هرگز نمی‌دانید که کدام یک طولانی‌ترین زمان را می‌برند! این برای تعیین اینکه کدام یک باید بهینه شوند کلیدی است و بیشترین صرفه جویی در هزینه را برای شما در پایگاه داده ابری شما خواهد داشت.

یکی از ابزارهای بهینه سازی عملکرد، پروفایل کوئری است. این به شما امکان می دهد تا با مشاهده آمارهایی مانند زمان اجرا و ردیف های برگشتی، منبع مشکلات عملکرد را مشخص کنید. پروفایل کوئری همچنین شامل طرح های اجرای کوئری است که به شما بینشی در مورد اینکه چه کدی قبل از اجرا با چه ترتیبی اجرا می شود، می دهد. برای بهینه سازی عملکرد کوئری ، همچنین می توانید به گزارش های پایگاه داده، خود سرور و هر برنامه خارجی متصل به پایگاه داده ابری خود نگاه کنید.

10. به جای UNION از UNION ALL استفاده کنید

UNION یک عملگر است که برای پیوستن به خروجی های دو کوئری SQL استفاده می شود. زمانی که نیاز به ترکیب دو مجموعه داده که نام ستون‌های یکسانی دارند، مفید است. با این حال، مهم است که تفاوت بین دو اپراتور UNION - UNION و UNION ALL را درک کنید.

UNION همه سطرهای جدول A را به تمام سطرهای جدول B می پیوندد. هیچ تکراری رخ نمی دهد. با این حال، UNION ALL همه سطرهای جدول A را با تمام سطرهای جدول B می‌پیوندد و سپس ردیف‌هایی را که مقادیر یکسانی دارند حذف می‌کند. اگر به موارد تکراری اهمیتی نمی دهید، UNION در مقایسه با UNION ALL در زمان پردازش شما صرفه جویی می کند. من معمولاً همیشه UNION را انتخاب می کنم زیرا، حتی اگر موارد تکراری وجود داشته باشد، می خواهم در مورد آنها بدانم و وقت بگذارم تا بفهمم چرا این اتفاق می افتد.

11. عملکرد های فرعی را بهینه کنید

در حالی که من استفاده از ساب کوئری ها را هنگام تلاش برای بهینه‌سازی عملکرد توصیه نمی‌کنم، گاهی اوقات هنگام انجام یک تحلیل سریع و کثیف سریع و مفید هستند. اگر لازم است کاری انجام دهید مانند بررسی اینکه آیا مقادیر در جدول دیگری یا زیرکوئری sql وجود دارد یا خیر، بهتر است از عبارت EXISTS به جای دستور IN استفاده کنید.

EXISTS یک مقدار بولی را برمی‌گرداند، به سرعت مقادیر را با هم مقایسه می‌کند و زمانی که مقداری وجود ندارد به سراغ بعدی می‌رود. IN هر مقدار را مقایسه می کند زیرا خود مقدار را برمی گرداند و زمان پردازش کوئری را کند می کند. با این حال، IN برای استفاده کارآمدتر از چیزی مانند یک عبارت OR است که یک جدول را برای چندین شرایط مختلف اسکن می کند.

به جای این:

SELECT 
Customer_id 
FROM customer_details 
WHERE state_id=3 OR state_id=11 OR state_id=34 

این کار را انجام دهید:

SELECT 
Customer_id 
FROM customer_details 
WHERE state_id IN (3, 11, 34)

در این مورد، استفاده از عبارت IN به جای OR بسیار کارآمدتر است. با این حال، در مثال زیر، استفاده از EXISTS به جای OR منطقی تر است زیرا دو جدول مختلف با هم مقایسه می شوند.

به جای این:

SELECT customer_id FROM customer_details WHERE order_id IN (SELECT order_id FROM order_details WHERE order_type_id=3)

این کار را انجام دهید:

SELECT customer_id FROM customer_details WHERE EXISTS 
(SELECT * FROM order_details WHERE customer_details.customer_id = order_details.customer_id)

این کار به جای اسکن و مقایسه هر مقدار مانند یک عبارت IN، تمام ردیف هایی را که درست ثابت می شوند، برمی گرداند.

12. از ویژگی های خاص پایگاه داده ابری استفاده کنید

یکی از مزایای استفاده از پایگاه داده ابری، ویژگی های خاص پایگاه داده است که با آن همراه است. به عنوان مثال، Snowflake دارای تعداد زیادی توابع SQL خاص برای Snowflake است که ایجاد تغییرات را آسان تر می کند. اینها شامل توابعی برای تجزیه مقادیر JSON و کار با انواع داده های مختلف است. با ارائه دهنده ابر خود بررسی کنید تا ببینید آیا آنها بهینه سازی های خاصی را توصیه می کنند یا خیر.

نتیجه

پایگاه داده ها ابزار قدرتمندی برای ارتقای محیط داده های شما به سطح بعدی هستند. آنها به شما انعطاف زیادی را می دهند، اما این بدان معنا نیست که باید عملکرد را فدا کنید. شما می توانید بسیاری از ویژگی های ارائه شده توسط این پایگاه های داده را در ترکیب با SQL هوشمندتر به منظور کاهش هزینه ها و بالا نگه داشتن عملکرد استفاده کنید.

بسیاری از این ترفندها در مورد دانستن این موضوع است که از کدام ویژگی ها در چه موقعیت هایی استفاده کنید. اما به همان اندازه مهم است که بدانید از چه توابع SQL باید اجتناب کرد. اکنون شما ابزارهایی را دارید که برای بررسی نحوه استفاده از SQL در پایگاه داده ابری خود و بهبود آن برای قابلیت اطمینان داده ها، کیفیت داده ها و دسترسی بهتر به داده ها نیاز دارید.