ایندکسِ مرکب در SQLite با ترتیبِ ستون‌ها تعریف می‌شود؛ داشتنِ همان نامِ ستون‌ها با ترتیبِ متفاوت الزاماً planیکسانی برای queryنمی‌سازد. به‌جایِ حدس دربارهٔ سریع‌ترشدن، یک پرس‌وجوی ثابت را با چند indexاجرا می‌کنیم، ردیف‌ها را برابر می‌خواهیم و EXPLAIN QUERY PLANِ همان نسخه را می‌خوانیم. این تمرین benchmarkِ زمان یا پیشنهادِ تغییرِ پایگاهِ اصلی نیست.
پرس‌وجو را ثابت نگه داریم
جدولِ اصیل۴۸ردیف دارد: idیکتا،state،createdِ عددی وcode. هر شناسهٔ بخش‌پذیر بر۳،openاست؛ createdاز باقیماندهٔ تقسیمِ idبر۵می‌آید. این دادهٔ ساختگی، زمانِ واقعیِ درخواست یا آمارِ مشتری نیست. queryفقط ردیف‌های openرا برcreatedو سپسidمرتب می‌کند و پنج ردیفِ اول را می‌خواهد.
مرجعِ مستقل با فیلتر وsortِ همان فهرست در Pythonساخته می‌شود. شناسه‌های مورد انتظار۱۵،۳۰،۴۵،۶و۲۱هستند. idبرای شکستنِ تساویِ createdداخلِ ORDER BYآمده است؛ اگر ترتیبِ کامل نداشته باشیم، عوض‌شدنِ ردیف‌های هم‌زمان را ممکن است اشتباهاً نتیجهٔ تغییرِ ایندکس بدانیم.
چهار ساختار، یک خروجی
برای هر حالت، پایگاهِ حافظه‌ایِ تازه با همان schemaو داده می‌سازیم: بدونِ indexِ پیشنهادی،indexِ state/created/id،indexِ created/state/idو در آخرstate/created/id/code. تنها همین indexاضافی بین حالت‌ها فرق دارد؛ کلیدِ اصلیِ idدر همهٔ آن‌ها وجود دارد.
| حالت | ترتیبِ ستونِ پیشنهادی | مشاهدهٔ اجرای این نسخه |
|---|---|---|
| بدونِ indexِ اضافه | ندارد | SCANو مرتب‌سازیِ موقت |
| stateاول | state،created،id | SEARCHبا شرطِstate |
| createdاول | created،state،id | SCANباindexومرتب‌سازیِ بخشِ آخر |
| پوشاننده | state،created،id،code | SEARCHباCOVERING INDEX |
تمامِ نتیجه‌ها، شاملِ codeوcreated،با مرجعِ مستقل برابرند. فایلِ JSONنسخهٔ SQLiteو سطرهای واقعیِ planرا نگه می‌دارد؛ جدولِ بالا تفسیرِ همین اجراست و برای همهٔ نسخه‌ها و داده‌ها الزامِ ثابت نیست.
ستونِ اول و شکستنِ تساوی
در توضیحِ رسمیِ SQLite،ستونِ چپ‌تر ابتدا ترتیبِ indexرا تعیین می‌کند و ستون‌های بعدی تساوی‌های آن را می‌شکنند. وقتی stateبا برابری محدود شده است، ادامهٔ createdوidمی‌تواند با ترتیبِ مورد نیازِ همین queryهم‌راستا باشد. جابه‌جاییِ stateوcreatedاین قراردادِ دسترسی را عوض می‌کند.
این توضیح به معنیِ قانونِ «ستونِ کم‌تکرار همیشه اول» یا نسخهٔ یکسان برای هر queryنیست. فیلترِ بازه‌ای،جهتِsort،آمارِ داده و دیگر پرس‌وجوها هم در تصمیمِ واقعی نقش دارند. نمونهٔ کوچک فقط نشان می‌دهد چگونه از یک سؤالِ دقیق و planِ مشاهده‌شده شروع کنیم؛ indexهای واقعی را بی‌بررسی حذف نکنید.
SCAN به معنیِ نبودِ index نیست
راهنمای EXPLAIN QUERY PLANتوضیح می‌دهد SCANمی‌تواند پیمایشِ همهٔ رکوردها به ترتیبِ یک indexهم باشد؛ SEARCHبازدید از زیرمجموعه را نشان می‌دهد. در حالتِ createdاول،نامِ indexدر همان سطرِ SCANدیده می‌شود. بنابراین جست‌وجوی صرفِ واژهٔSCANو برچسبِ خودکارِ «بدون ایندکس» برداشتِ درستی نیست.
پوشاننده‌بودن هم به ستون‌های لازمِ queryوابسته است. وقتی codeدر آخرِ indexاضافه می‌شود،هم شرط و ترتیب و هم ستون‌های خروجیِ نمونه در indexقرار دارند. اگر queryستونِ دیگری بخواهد،همین توضیح ممکن است دیگر برقرار نباشد؛ پوشاننده ویژگیِ رابطهٔ indexبا queryاست،نه نشانِ همیشگیِ یک نام.
plan را APIِ پایدار یا سنجشِ سرعت ننامیم
مستندِ رسمی هشدار می‌دهد قالبِ خروجیِ EXPLAIN QUERY PLANمی‌تواند بینِ نسخه‌ها تغییر کند. آزمونِ ما رشتهٔ planرا برای همهٔ آینده ثابت نمی‌خواهد؛ فقط خروجیِ ردیف‌ها را با مرجع می‌سنجد و متنِ مشاهده‌شده را برای خواندن ثبت می‌کند. برنامهٔ عملیاتی را بر مبنایِ شمارهٔ گره یا یک عبارتِ ثابت از این خروجی نسازید.
زمان،حافظه،حجمِ indexو بارِ نوشتن اندازه‌گیری نشده‌اند. کاهشِ یک مرحلهٔsortدر این۴۸ردیف،درصدِ سرعتِ پروژهٔ شما را ثابت نمی‌کند. هر تصمیمِ بهینه‌سازی به queryها و دادهٔ واقعیِ مجاز و سنجشِ متناسب نیاز دارد؛ این تمرین هزینه یا ابزارِ تازه‌ای نمی‌خواهد.
این index با ANN فرق دارد
جست‌وجوی ANN کیفیتِ تقریب و نامزدهای هندسی را می‌سنجد؛ اینجا ترتیبِ رابطه‌ای و planِ SQLiteداریم. اتصالِ رکوردِ برداری به متن هم صحتِ منبع را کنترل می‌کند،نه این پرس‌وجویِ فیلتر وsort.
برای بررسیِ اتصالِ داده در راهکارهای اپرا،queryو انتظارِ ردیف را با مسئولِ فنی روشن کنید. این مقاله نوعِ پایگاه یا indexِ داخلیِ اپرا را اعلام نمی‌کند؛ هدف این است که پیشنهادِ بهینه‌سازی قابلِ مشاهده و قابلِ سنجش باشد.
فایل تمرین و منبع
کدِ کاملِ محلی و کنترل‌های اصیلِ تمرین · دادهٔ ساختگی و خروجیِ اجرای واقعی
- SQLite Query Planning،بخش‌های۱٫۶،۱٫۷و۳٫۱؛ ترتیبِ چندستونی وcovering؛ فقط بخش‌های مرتبط خوانده شدند
- SQLite EXPLAIN QUERY PLAN،هشدارِ ناپایداریِ قالب و بخش۱٫۱و۱٫۲؛ صفحه با به‌روزرسانی۳۱مه۲۰۲۵
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.