全部产品
Search

搜索本产品

    AnalyticDB：Penulisan dan kueri

    文档中心

    AnalyticDB：Penulisan dan kueri

    更新时间：Feb 04, 2026

    Topik ini menjelaskan masalah umum dan solusinya terkait penulisan dan pengkuerian data di AnalyticDB for MySQL.

    Catatan

    Jika edisi produk tidak disebutkan dalam suatu FAQ, pertanyaan tersebut hanya berlaku untuk AnalyticDB for MySQL Data Warehouse Edition.

    Ikhtisar FAQ

    Apakah kluster Enterprise Edition, Basic Edition, dan Data Lakehouse Edition mendukung pengkuerian data dari tabel Hudi menggunakan JDBC?

    Ya. Setelah Anda membuat tabel Hudi di kluster Enterprise Edition, Basic Edition, atau Data Lakehouse Edition, Anda dapat langsung mengkueri data dari tabel Hudi tersebut menggunakan JDBC.

    Dapatkah saya membaca data dari tabel Hudi di OSS menggunakan kluster Enterprise Edition, Basic Edition, atau Data Lakehouse Edition?

    Ya. Untuk informasi selengkapnya tentang cara membaca data dari tabel Hudi di OSS menggunakan tabel eksternal, lihat Impor data menggunakan tabel eksternal di kluster Data Lakehouse Edition.

    Apakah kluster Enterprise Edition, Basic Edition, atau Data Lakehouse Edition mendukung alih otomatis antara pekerjaan XIHE Massively Parallel Processing (MPP) dan pekerjaan XIHE BSP?

    Saat mengirimkan pekerjaan, Anda harus secara manual menentukan apakah akan mengirimkannya ke kelompok sumber daya Interactive atau Job. Hal ini menentukan apakah pekerjaan tersebut merupakan pekerjaan XIHE MPP atau XIHE BSP.

    Bagaimana cara memilih antara XIHE MPP dan XIHE BSP untuk menjalankan pekerjaan di kluster Enterprise Edition, Basic Edition, atau Data Lakehouse Edition?

    Secara default, XIHE BSP mengirimkan pekerjaan secara asinkron. Perbedaan antara pengiriman sinkron dan asinkron adalah apakah client perlu menunggu hingga kueri selesai dijalankan.

    Pengiriman asinkron memiliki batasan berikut:

    • Maksimal 10.000 baris dapat dikembalikan dalam satu set hasil.

    • Set hasil, termasuk tautan unduh file CSV-nya, disimpan maksimal selama 30 hari. Maksimal 1.000 set hasil dapat disimpan.

    Gunakan pengiriman asinkron untuk kueri yang memiliki waktu eksekusi lama dan memerlukan komputasi besar tetapi menghasilkan set hasil kecil, seperti INSERT INTO SELECT, INSERT OVERWRITE SELECT, dan CREATE TABLE AS SELECT.

    Bagaimana cara melihat status pekerjaan XIHE BSP di kluster Enterprise Edition, Basic Edition, atau Data Lakehouse Edition?

    • Jika pekerjaan XIHE BSP dikirimkan dari Job Editor pada halaman SQL Development, Anda dapat melihat statusnya di tab Execution Records.

    • Jika pekerjaan XIHE BSP tidak dikirimkan dari job editor, Anda dapat melihat statusnya menggunakan tabel memori bawaan. Untuk melakukannya, jalankan pernyataan berikut:

      SELECT status FROM information_schema.kepler_meta_elastic_job_list WHERE process_id='<job_id>';

      Untuk mengkueri statistik status pekerjaan XIHE BSP, jalankan pernyataan berikut:

      SELECT status,count(*) FROM information_schema.kepler_meta_elastic_job_list GROUP BY status;

    Bagaimana cara menerapkan isolasi resource untuk mengurangi gangguan antar tugas SQL?

    Kluster Data Warehouse Edition dalam mode elastis dan kluster Enterprise Edition, Basic Edition, dan Data Lakehouse Edition mendukung kelompok sumber daya. Untuk informasi selengkapnya tentang jenis kelompok sumber daya, lihat Kelompok sumber daya untuk Data Warehouse Edition dan Kelompok sumber daya untuk Data Lakehouse Edition. Anda dapat membuat berbagai jenis kelompok sumber daya dan mengirimkan pekerjaan SQL ke kelompok sumber daya yang sesuai untuk mencapai isolasi resource.

    Bagaimana menangani jumlah kondisi IN yang berlebihan?

    AnalyticDB for MySQL membatasi jumlah kondisi IN. Batas default adalah 2.000. Anda dapat menyesuaikan batas ini sesuai kebutuhan.

    Catatan

    Jumlah kondisi IN tidak boleh melebihi 5.000. Melebihi batas ini akan memengaruhi performa.

    Sebagai contoh, untuk mengatur batas jumlah kondisi IN menjadi 3.000, jalankan pernyataan berikut:

    SET ADB_CONFIG max_in_items_count=3000;

    Bagaimana menyelesaikan error "Query exceeded maximum time limit of 1800000.00ms" saat mengkueri data?

    AnalyticDB for MySQL menetapkan periode timeout untuk kueri SQL. Error ini terjadi karena kueri SQL melebihi timeout default 1.800.000,00 ms. Anda dapat mengonfigurasi timeout kueri untuk satu kueri tunggal atau untuk semua kueri dalam kluster. Contoh berikut menunjukkan cara mengonfigurasi timeout kueri:

    • Berlaku untuk satu kueri.

      /*+ QUERY_TIMEOUT=xxx */SELECT count(*) FROM t;

    • Berlaku untuk semua kueri di seluruh kluster.

      SET ADB_CONFIG QUERY_TIMEOUT=xxx;

      Untuk informasi selengkapnya, lihat Parameter konfigurasi umum.

    Bagaimana menyelesaikan error "Out of Memory Pool size pre cal. available 0 require 3" saat mengkueri data?

    Penyebab: Pernyataan SQL besar sedang dijalankan di kluster AnalyticDB for MySQL. Pernyataan semacam ini mengonsumsi banyak memori, sehingga menyebabkan error kehabisan memori saat Anda menjalankan kueri SQL saat ini.

    Solusi: Tunggu beberapa menit, lalu jalankan kembali pernyataan SQL tersebut.

    Bagaimana menyelesaikan error "STORAGE_INDEX_ERROR, msg:Index does not exist" saat mengkueri data?

    Penyebab: Error ini disebabkan oleh bug yang diketahui pada beberapa versi kernel awal AnalyticDB for MySQL. Dalam kondisi tertentu, bug ini dapat menyebabkan inkonsistensi metadata indeks tabel. Akibatnya, indeks tidak ditemukan saat kueri dijalankan, sehingga memicu exception STORAGE_INDEX_ERROR.

    Solusi: Upgrade versi kernel kluster Anda. Bug ini telah diperbaiki pada versi kernel baru.

    Penting

    • Durasi upgrade: Upgrade versi kernel biasanya memakan waktu sekitar 30 menit.

    • Gangguan layanan: Selama upgrade, kluster Anda mengalami pemutusan sementara yang berlangsung beberapa detik.

    • Rekomendasi: Kami sangat menyarankan agar Anda melakukan upgrade selama jendela pemeliharaan yang direncanakan atau jam sepi. Pastikan aplikasi Anda memiliki mekanisme rekoneksi otomatis untuk menangani pemutusan sementara tersebut dengan lancar.

    Bagaimana menyelesaikan error "multi-statement be found" saat menggunakan fitur multi-statement untuk menjalankan beberapa pernyataan SQL secara berurutan?

    Hanya kluster dengan versi kernel 3.1.9.3 atau lebih baru yang mendukung fitur multi-statement. Pertama, periksa apakah versi kernel kluster Anda memenuhi persyaratan ini. Jika versi kernel lebih awal dari 3.1.9.3, hubungi dukungan teknis untuk melakukan upgrade versi. Jika versi kernel 3.1.9.3 atau lebih baru tetapi error masih terjadi, fitur multi-statement mungkin belum diaktifkan pada client.

    Sebagai contoh, saat Anda menggunakan client JDBC MySQL untuk terhubung ke kluster, Anda tidak hanya perlu menjalankan perintah SET ADB_CONFIG ALLOW_MULTI_QUERIES=true; untuk mengaktifkan fitur multi-statement secara manual, tetapi juga mengatur properti koneksi JDBC allowMultiQueries menjadi true.

    Bagaimana memecahkan masalah nilai waktu yang terpotong pada hasil kueri?

    Pertama, verifikasi hasilnya menggunakan client MySQL. Jika client MySQL menampilkan nilai waktu dengan benar, periksa apakah perangkat lunak client lain yang Anda gunakan telah memproses hasil tersebut dengan cara khusus.

    Bagaimana menyelesaikan error pada fungsi bawaan AES_ENCRYPT?

    Pernyataan berikut menyebabkan error. 

     SELECT CONVERT(AES_DECRYPT(AES_ENCRYPT('ABC123','key_string'),'key_string'),char(10));

    Penyebabnya adalah dalam pernyataan AES_ENCRYPT(varbinary x, varchar y), tipe data x harus berupa varbinary. Kode berikut memberikan contoh pernyataan SQL yang valid:

    SELECT CONVERT(AES_DECRYPT(AES_ENCRYPT(CAST('ABC123' AS VARBINARY), 'key_string'), 'key_string'),char(10));

    Mengapa hasil kueri saya berfluktuasi?

    Jika Anda memastikan bahwa data tidak diperbarui, hasil kueri mungkin berfluktuasi karena alasan berikut:

    • LIMIT tanpa pengurutan: AnalyticDB for MySQL adalah database terdistribusi. Kueri dijalankan pada beberapa node secara multi-threaded. Jika beberapa thread mengembalikan cukup baris untuk memenuhi kondisi LIMIT, kueri akan berhenti. Oleh karena itu, hasil kueri dengan klausa LIMIT tanpa pengurutan bersifat acak karena sistem tidak dapat menjamin bahwa hasil dikembalikan dari kumpulan thread yang tetap.

    • Kueri agregat dengan pengelompokan: Jika suatu bidang dalam klausa SELECT tidak memiliki fungsi agregat dan tidak termasuk dalam klausa GROUP BY, nilai acak akan dikembalikan untuk bidang tersebut.

    Jika masalah berlanjut, hubungi dukungan teknis.

    Mengapa kueri ORDER BY pada satu tabel memakan waktu lama?

    Penyebab: Data tidak diurutkan di lapisan penyimpanan dan disimpan secara tersebar. Hal ini menyebabkan banyak data tidak valid dibaca, sehingga meningkatkan waktu kueri.

    Solusi: Tambahkan indeks terkluster pada bidang yang digunakan untuk klausa ORDER BY. Setelah Anda menambahkan indeks terkluster, data akan diurutkan sebelumnya di lapisan penyimpanan. Saat Anda menjalankan kueri ORDER BY, hanya sedikit data yang perlu dibaca, sehingga meningkatkan performa kueri. Untuk informasi selengkapnya tentang cara menambahkan indeks terkluster, lihat Tambahkan indeks terkluster.

    Catatan

    • Satu tabel hanya dapat memiliki satu indeks terkluster. Jika bidang lain sudah memiliki indeks terkluster, Anda harus menghapusnya terlebih dahulu sebelum dapat menambahkan indeks terkluster pada bidang ORDER BY.

    • Menambahkan indeks terkluster pada tabel besar meningkatkan waktu yang diperlukan untuk tugas BUILD, yang pada gilirannya memengaruhi pemanfaatan CPU pada node penyimpanan.

    Mengapa jumlah total baris pemindaian tabel dalam rencana eksekusi tidak sama dengan jumlah total baris yang dipindai dalam kueri?

    Masalah ini biasanya disebabkan oleh pembuatan tabel replikasi. Di AnalyticDB for MySQL, salinan data dari tabel replikasi disimpan di setiap shard. Saat Anda mengkueri tabel replikasi, jumlah pemindaian dihitung berulang kali.

    Mengapa penggunaan INSERT OVERWRITE pada tabel tanpa primary key menghasilkan data duplikat?

    AnalyticDB for MySQL tidak secara otomatis menghapus duplikat dari tabel yang tidak memiliki primary key.

    Mengapa saya mendapatkan error "Column 'XXX' not in GROUP BY clause" saat menjalankan SELECT * FROM TABLE GROUP BY KEY?

    Pernyataan SELECT * FROM table GROUP BY key tidak didukung untuk kueri pengelompokan. Anda harus secara eksplisit mencantumkan semua bidang. Kode berikut memberikan contoh pernyataan SQL yang valid:

    SELECT nation.name FROM nation GROUP BY nation.nationkey

    Apakah ada batasan jumlah nilai dalam operator IN ketika hasil kueri dikembalikan dalam format JSON?

    Untuk kluster AnalyticDB for MySQL dengan versi kernel 3.1.4 atau lebih awal, jumlah nilai yang ditentukan dalam operator IN tidak boleh melebihi 16. Untuk kluster dengan versi kernel lebih baru dari 3.1.4, tidak ada batasan. Untuk informasi tentang cara melihat versi kernel kluster, lihat Bagaimana cara melihat versi kernel kluster?.

    Dapatkah saya menggunakan file CSV terkompresi GZIP di OSS sebagai sumber data eksternal?

    AnalyticDB for MySQL mendukung file CSV terkompresi GZIP di OSS sebagai sumber data eksternal, dan Anda harus menambahkan compress_type=gzip ke definisi tabel eksternal. Untuk sintaks tabel eksternal OSS, lihat Tabel eksternal OSS non-partisi.

    Apakah INSERT ON DUPLICATE KEY didukung?

    AnalyticDB for MySQL saat ini hanya mendukung pembaruan nilai, bukan ekspresi aritmetika.

    Apakah Join didukung dalam pernyataan UPDATE?

    Fitur ini hanya didukung di kluster AnalyticDB for MySQL dengan versi kernel 3.1.6.4 atau lebih baru. Untuk informasi selengkapnya, lihat UPDATE.

    Dapatkah saya mengatur variabel dalam SQL?

    AnalyticDB for MySQL tidak mendukung pengaturan variabel dalam SQL.

    Dapatkah saya menggunakan plugin Logstash untuk menyisipkan data secara massal dengan pernyataan INSERT ON DUPLICATE KEY UPDATE?

    Ya. Saat Anda menggunakan pernyataan INSERT ON DUPLICATE KEY UPDATE untuk menyisipkan data secara massal, Anda tidak perlu menambahkan ON DUPLICATE KEY UPDATE setelah setiap klausa VALUES(). Anda hanya perlu menambahkannya setelah klausa VALUES() terakhir.

    Sebagai contoh, untuk menyisipkan tiga catatan secara massal ke tabel student_course, jalankan pernyataan berikut:

    INSERT INTO student_course(`id`, `user_id`, `nc_id`, `nc_user_id`, `nc_commodity_id`, `course_no`, `course_name`, `business_id`)
VALUES(277943, 11056941, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', 'Industrial Accounting Practice V9.0--77', 'accounting'),
(277944, 11056943, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', 'Industrial Accounting Practice V9.0--88', 'accounting'),
(277945, 11056944, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', 'Industrial Accounting Practice V9.0--99', 'accounting')
ON DUPLICATE KEY UPDATE
course_name = 'Industrial Accounting Practice V9.0--77',
business_id = 'accounting';

    Apa prasyarat untuk memuat dataset bawaan?

    Kluster harus memiliki minimal 24 AnalyticDB Compute Units (ACU) sumber daya penyimpanan yang dipesan, dan kelompok sumber daya user_default harus memiliki minimal 16 ACU sumber daya komputasi yang dipesan.

    Bagaimana cara mengetahui apakah dataset bawaan berhasil dimuat?

    Di halaman Job Development > SQL Development, Anda dapat melihat progres pemuatan. Dataset berhasil dimuat jika tombol Load Built-in Dataset berubah menjadi abu-abu dengan ikon 1, dan database ADB_SampleData_TPCH beserta tabel-tabelnya terlihat di tab Databases and Tables.

    Apa yang harus saya lakukan jika pemuatan dataset bawaan gagal atau memakan waktu lama?

    Pertama, jalankan pernyataan SQL DROP TABLE table_name; untuk menghapus semua tabel di database. Setelah tabel dihapus, jalankan pernyataan SQL DROP DATABASE ADB_SampleData_TPCH; untuk menghapus database dataset bawaan. Setelah database ADB_SampleData_TPCH dihapus, muat ulang dataset tersebut.

    Bagaimana akun database standar dapat menggunakan dataset bawaan?

    Fitur dataset bawaan mengikuti aturan pengelolaan izin AnalyticDB for MySQL. Meskipun dataset bawaan telah dimuat di kluster, akun database standar tidak dapat menggunakannya tanpa izin untuk database ADB_SampleData_TPCH. Akun istimewa harus memberikan izin yang diperlukan kepada akun standar. Pernyataan pemberian izinnya adalah:

    GRANT select ON ADB_SampleData_TPCH.* TO <user_name>;

    Bagaimana cara menguji dataset bawaan setelah dimuat?

    Setelah dataset dimuat, AnalyticDB for MySQL menyediakan skrip kueri yang sesuai secara default. Anda dapat menjalankan pernyataan kueri contoh di tab Scripts pada halaman SQL Development. Untuk informasi selengkapnya tentang pernyataan kueri tersebut, lihat Dataset uji TPC-H.

    Penting

    Untuk memastikan integritas data, kami merekomendasikan agar Anda hanya menjalankan operasi kueri pada database ADB_SampleData_TPCH. Jika status pemuatan dataset menjadi abnormal akibat perubahan DDL atau DML, coba hapus database ADB_SampleData_TPCH dan muat ulang dataset tersebut.