All Products
Search
Document Center

PolarDB:Kolam koneksi

Last Updated:Jul 18, 2026

PolarDB mendukung dua jenis kolam koneksi: tingkat sesi dan tingkat transaksi. Kolam koneksi mengurangi beban koneksi database dengan menggunakan kembali koneksi yang sudah ada, alih-alih membuat koneksi baru untuk setiap permintaan.

Kolam koneksi yang dijelaskan di sini merupakan fitur dari PolarProxy—lapisan proksi PolarDB. Fitur ini tidak memengaruhi kolam koneksi apa pun yang dibangun di dalam aplikasi Anda. Jika aplikasi Anda sudah mengelola kolam koneksi sendiri, Anda tidak perlu mengaktifkan fitur ini.

Cara kerja

Kolam koneksi tingkat sesi

Session-level connection pool diagram

Saat koneksi aplikasi ditutup, PolarProxy memeriksa apakah koneksi tersebut menganggur. Jika menganggur, PolarProxy menyimpannya dalam kolam selama periode singkat. Permintaan masuk berikutnya akan menggunakan kembali koneksi menganggur tersebut jika parameter user, clientip, dan dbname sesuai—menghemat biaya pembukaan koneksi baru. Jika tidak ditemukan kecocokan, PolarProxy membuka koneksi baru ke database.

Kolam tingkat sesi mengurangi frekuensi pembentukan koneksi, sehingga menurunkan jumlah thread utama MySQL yang digunakan dan meningkatkan throughput. Namun, kolam ini tidak mengurangi jumlah total koneksi bersamaan; koneksi menganggur tetap dihitung terhadap batas koneksi database.

Kolam koneksi tingkat transaksi

Transaction-level connection pool diagram

Kolam tingkat transaksi mengurangi baik jumlah koneksi langsung ke database maupun beban dari koneksi singkat. Aplikasi dapat membuka ribuan koneksi ke PolarProxy, sementara PolarProxy hanya mempertahankan puluhan atau ratusan koneksi ke node backend database.

Saat aplikasi mengirim permintaan, PolarProxy tidak langsung membuka koneksi backend. PolarProxy memeriksa kolam untuk mencari koneksi menganggur yang sesuai dengan user, dbname, dan variabel sistem (sql_mode, character_set_server, collation_server, time_zone). Jika ditemukan kecocokan, PolarProxy menggunakan kembali koneksi tersebut. Setelah transaksi selesai, koneksi dikembalikan ke kolam untuk permintaan lain.

PolarProxy tidak menerapkan batas jumlah koneksi di sisi aplikasi. Jumlah koneksi maksimum ke titik akhir kluster PolarDB bergantung pada spesifikasi node komputasi backend. Tanpa kolam tingkat transaksi, sistem harus membuka koneksi terpisah di node primary dan di setiap node read-only untuk setiap permintaan.

Pilih jenis kolam koneksi

Gunakan tabel berikut untuk mencocokkan skenario Anda dengan jenis kolam yang tepat:

Scenario Recommended pool Reason
Jumlah koneksi sedikit, sebagian besar persisten, atau aplikasi sudah memiliki kolam koneksi sendiri None (disable) Kolam PolarDB menambahkan beban tanpa manfaat
Puluhan ribu koneksi, atau arsitektur tanpa server dengan koneksi yang meningkat secara linear Transaction-level Melakukan multiplexing banyak koneksi aplikasi menjadi lebih sedikit koneksi backend
Hanya koneksi singkat, dalam skenario yang tercantum di bagian Batasan tingkat transaksi Session-level Mengurangi frekuensi koneksi tanpa memerlukan multiplexing penuh
Eksekusi COM_STATISTICS yang sering None (disable) Mengaktifkan kolam mengubah koneksi non-persisten menjadi persisten, meningkatkan jumlah koneksi persisten dan memicu bottleneck lock-then-traverse di COM_STATISTICS. Eksekusi yang sering dapat menyebabkan degradasi performa serius dan memengaruhi waktu respons keseluruhan bisnis.
Sejumlah besar pernyataan SQL lambat yang menyebabkan koneksi tertunda None (disable) Kolam koneksi tidak menyelesaikan kontensi akibat kueri lambat; kurangi kueri lambat sebagai gantinya

Batasan

Batasan tingkat sesi

  • Kolam tingkat sesi mengurangi frekuensi koneksi, bukan konkurensi. Koneksi menganggur dalam kolam tetap dihitung terhadap batas total koneksi database.

  • Kolam tingkat sesi tidak menyelesaikan koneksi tertunda yang disebabkan oleh pernyataan SQL lambat.

Batasan tingkat transaksi

Operasi berikut mengunci koneksi selama durasi sesi. Koneksi yang terkunci tidak dikembalikan ke kolam dan menjadi tidak tersedia untuk permintaan lain.

Operation Workaround
Menjalankan pernyataan PREPARE Gunakan prepared statement di sisi client jika driver Anda mendukungnya
Membuat tabel temporary Gunakan tabel biasa dengan pengenal sesi unik, lalu hapus setelah selesai
Memodifikasi variabel pengguna Atur variabel saat awal sesi, atau berikan nilai secara eksplisit dalam setiap kueri
Menerima entri log yang melebihi 16 MB Pecah penulisan log besar menjadi batch yang lebih kecil
Menjalankan pernyataan LOCK TABLE Gunakan kunci tingkat baris (SELECT ... FOR UPDATE) sebagai gantinya
Menjalankan beberapa pernyataan dalam satu string pernyataan Pisahkan menjadi pernyataan individual
Memanggil prosedur tersimpan Pindahkan logika ke lapisan aplikasi jika memungkinkan

Fungsi yang tidak didukung

FOUND_ROWS(), ROW_COUNT(), dan LAST_INSERT_ID() dapat dipanggil tetapi mungkin mengembalikan hasil yang tidak akurat saat koneksi digunakan kembali.

Function Workaround
FOUND_ROWS() Pada PolarProxy V1.13.11 atau yang lebih baru, letakkan SELECT FOUND_ROWS() segera setelah SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT *. Perlu diperhatikan bahwa metode ini tidak lagi direkomendasikan oleh MySQL open source. Sebagai alternatif, ganti dengan SELECT COUNT(*) FROM tb1. Untuk detailnya, lihat FOUND_ROWS().
LAST_INSERT_ID() Letakkan SELECT LAST_INSERT_ID() segera setelah pernyataan INSERT untuk mendapatkan hasil yang akurat.
ROW_COUNT() Tidak ada solusi alternatif; fungsi ini dapat dipanggil tetapi mungkin mengembalikan hasil yang tidak akurat saat koneksi digunakan kembali.

Perbedaan perilaku lainnya

  • `wait_timeout`: Saat timeout berakhir, hanya koneksi backend yang ditutup. Koneksi di sisi aplikasi ke PolarProxy tetap terbuka karena PolarProxy memilih koneksi dari kolam untuk setiap permintaan baru.

  • Variabel sesi: Kolam mencocokkan koneksi menggunakan sql_mode, character_set_server, collation_server, dan time_zone. Jika permintaan Anda bergantung pada variabel sistem tingkat sesi lainnya, jalankan pernyataan SET untuk mengonfigurasinya setelah setiap koneksi dibentuk. Jika tidak, kolam mungkin menggunakan kembali koneksi dengan nilai variabel yang tidak diharapkan.

  • Tingkat isolasi: Pertahankan tingkat isolasi default READ COMMITTED. Jika client secara eksplisit mengubah tingkat isolasi, koneksi dikembalikan ke kolam setelah transaksi berakhir dan mungkin digunakan kembali oleh permintaan lain, menyebabkan ketidakkonsistenan tingkat isolasi.

  • `SELECT connection_id()`: Mungkin mengembalikan ID thread yang berbeda untuk koneksi yang tampak sama, karena koneksi digunakan kembali di berbagai permintaan.

  • `SHOW PROCESSLIST` dan Penjelajah SQL: Alamat IP dan nomor port yang ditampilkan mungkin berbeda dari alamat IP dan port aktual aplikasi Anda, karena koneksi dimultiplex melalui PolarProxy.

  • Perintah `KILL`: Mengembalikan ERROR 1094 (HY000): Unknown thread id: xxx karena ID thread antara client dan PolarProxy berbeda dari ID thread antara PolarProxy dan database. PolarProxy menggabungkan hasil SHOW PROCESSLIST dari semua node sebelum mengembalikannya ke client.

Catatan penggunaan

  • Pengaturan kolam koneksi hanya berlaku untuk koneksi yang dibuat setelah perubahan dilakukan. Koneksi yang sudah ada tidak terpengaruh. Untuk langkah-langkah konfigurasi, lihat Configure PolarProxy.

  • Kolam koneksi tidak mendukung izin berbasis IP untuk suatu akun. Jika Anda memberikan akses user@192.xx.xx.1 ke database_a tetapi tidak memberikan akses kepada user@192.xx.xx.2, kesalahan izin mungkin terjadi saat koneksi tersebut digunakan kembali. Hindari mengonfigurasi izin berbeda untuk akun yang sama di alamat IP berbeda saat pooling koneksi diaktifkan.