Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Membaca Aurora DSQL JELASKAN rencana
Memahami cara membaca rencana EXPLORE adalah kunci untuk mengoptimalkan kinerja kueri. Di bagian ini, kita akan menelusuri contoh nyata dari rencana kueri Aurora DSQL, menunjukkan bagaimana berbagai jenis pemindaian berperilaku, menjelaskan di mana filter diterapkan, dan menyoroti peluang untuk pengoptimalan.
Contoh Pemindaian Lengkap
Aurora DSQL memiliki Pemindaian Berurutan, yang secara fungsional identik dengan PostgreSQL, serta Pemindaian Penuh. Satu-satunya perbedaan antara keduanya adalah bahwa Full Scan dapat memanfaatkan penyaringan ekstra pada penyimpanan. Karena ini, hampir selalu dipilih di atas Pemindaian Berurutan. Karena kesamaannya, kami hanya akan membahas contoh Pemindaian Penuh yang lebih menarik.
Pemindaian Penuh sebagian besar akan digunakan pada tabel tanpa kunci utama. Karena kunci primer Aurora DSQL secara default mencakup indeks penuh, Aurora DSQL kemungkinan besar akan menggunakan Index Only Scan pada kunci utama dalam banyak situasi di mana PostgreSQL akan menggunakan Sequential Scan. Seperti kebanyakan database lainnya, tabel tanpa indeks di atasnya akan berskala buruk.
EXPLAIN SELECT account_id FROM transaction WHERE transaction_date > '2025-01-01' AND description LIKE '%external%';
QUERY PLAN
----------------------------------------------------------------------------------------------------------------
Full Scan (btree-table) on transaction (cost=125100.05..177933.38 rows=33333 width=16)
Filter: (description ~~ '%external%'::text)
-> Storage Scan on transaction (cost=12510.05..17793.38 rows=66666 width=16)
Projections: account_id, description
Filters: (transaction_date > '2025-01-01 00:00:00'::timestamp without time zone)
-> B-Tree Scan on transaction (cost=12510.05..17793.38 rows=100000 width=30)
Rencana ini menunjukkan dua filter yang diterapkan pada tahap yang berbeda. transaction_date >
'2025-01-01'Kondisi ini diterapkan pada lapisan penyimpanan, mengurangi berapa banyak data yang dikembalikan. description LIKE '%external%'Kondisi ini diterapkan kemudian di prosesor kueri, setelah data ditransfer, membuatnya kurang efisien. Mendorong filter yang lebih selektif ke dalam lapisan penyimpanan atau indeks umumnya meningkatkan kinerja.
Contoh Index Only Scan
Index Only Scan adalah jenis pemindaian yang paling optimal di Aurora DSQL karena menghasilkan perjalanan pulang pergi paling sedikit ke lapisan penyimpanan dan dapat melakukan pemfilteran paling banyak. Tetapi hanya karena Anda melihat Index Only Scan tidak berarti Anda memiliki rencana terbaik. Karena semua tingkat penyaringan yang berbeda yang dapat terjadi, penting untuk tetap memperhatikan berbagai tempat penyaringan dapat terjadi.
EXPLAIN SELECT balance FROM account WHERE customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb' AND balance > 100 AND status = 'pending';
QUERY PLAN
-------------------------------------------------------------------------------
Index Only Scan using idx1 on account (cost=725.05..1025.08 rows=8 width=18)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
Filter: (balance > '100'::numeric)
-> Storage Scan on idx1 (cost=12510.05..17793.38 rows=9 width=16)
Projections: balance
Filters: ((status)::text = 'pending'::text)
-> B-Tree Scan on idx1 (cost=12510.05..17793.38 rows=10 width=30)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
Dalam rencana ini, kondisi indeks,customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'), dievaluasi terlebih dahulu selama pemindaian indeks, yang merupakan tahap paling efisien karena membatasi berapa banyak data yang dibaca dari penyimpanan. Filter penyimpananstatus = 'pending',, diterapkan setelah data dibaca tetapi sebelum dikirim ke lapisan komputasi, mengurangi jumlah data yang ditransfer. Akhirnya, filter prosesor kueribalance > 100,, berjalan terakhir, setelah data dipindahkan, membuatnya paling tidak efisien. Dari jumlah tersebut, kondisi indeks memberikan kinerja terbesar karena secara langsung mengontrol berapa banyak data yang dipindai.
Contoh Pemindaian Indeks
Index Scan mirip dengan Index Only Scan, kecuali mereka memiliki langkah ekstra untuk memanggil ke tabel dasar. Karena Aurora DSQL dapat menentukan filter penyimpanan, ia dapat melakukannya baik pada panggilan indeks maupun panggilan pencarian.
Untuk memperjelas hal ini, Aurora DSQL menyajikan rencana sebagai dua node. Dengan cara ini, Anda dapat dengan jelas melihat seberapa banyak menambahkan kolom include akan membantu dalam hal baris yang dikembalikan dari penyimpanan.
EXPLAIN SELECT balance FROM account WHERE customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb' AND balance > 100 AND status = 'pending' AND created_at > '2025-01-01';
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Index Scan using idx1 on account (cost=728.18..1132.20 rows=3 width=18)
Filter: (balance > '100'::numeric)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
-> Storage Scan on idx1 (cost=12510.05..17793.38 rows=8 width=16)
Projections: balance
Filters: ((status)::text = 'pending'::text)
-> B-Tree Scan on account (cost=12510.05..17793.38 rows=10 width=30)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
-> Storage Lookup on account (cost=12510.05..17793.38 rows=4 width=16)
Filters: (created_at > '2025-01-01 00:00:00'::timestamp without time zone)
-> B-Tree Lookup on transaction (cost=12510.05..17793.38 rows=8 width=30)
Rencana ini menunjukkan bagaimana penyaringan terjadi di beberapa tahap:
-
Kondisi indeks pada data
customer_idfilter lebih awal. -
Filter penyimpanan pada
statuslebih lanjut mempersempit hasil sebelum dikirim ke komputasi. -
Filter prosesor kueri pada
balancediterapkan kemudian, setelah transfer. -
Filter pencarian
created_atdievaluasi saat mengambil kolom tambahan dari tabel dasar.
Menambahkan kolom yang sering digunakan sebagai INCLUDE bidang seringkali dapat menghilangkan pencarian ini dan meningkatkan kinerja.
Praktik Terbaik
-
Sejajarkan filter dengan kolom yang diindeks untuk mendorong pemfilteran sebelumnya.
-
Gunakan kolom INCLUDE untuk mengizinkan Pemindaian Hanya Indeks dan menghindari pencarian.
-
Selalu perbarui statistik untuk memastikan perkiraan biaya dan baris akurat.
-
Hindari kueri yang tidak diindeks pada tabel besar untuk mencegah Pemindaian Penuh yang mahal.