All Products
Search
Document Center

AnalyticDB:CREATE TABLE: Buat tabel partisi dan replikasi

Last Updated:May 22, 2026

Topik ini menjelaskan cara menggunakan sintaksis CREATE TABLE di AnalyticDB for MySQL untuk membuat tabel partisi dan tabel replikasi serta mendefinisikan kunci distribusi, kunci partisi, indeks, siklus hidup, dan penyimpanan berjenjangnya.

Strategi distribusi data

Sebelum membuat tabel, gunakan diagram ini untuk memahami konsep utama seperti shard, partisi, dan indeks terkluster.

Sintaksis

CREATE TABLE [IF NOT EXISTS] table_name
  ({column_name column_type [column_attributes] [ column_constraints ] [COMMENT 'column_comment']
  | table_constraints}
  [, ... ])
  [table_attribute]
  [partition_options]
  [index_all]
  [storage_policy]
  [block_size]
  [engine]
  [table_properties]
  [AS query_expr]
  [COMMENT 'table_comment']

column_attributes:
  [DEFAULT {constant | CURRENT_TIMESTAMP}]
  [AUTO_INCREMENT]

column_constraints:
  [{NOT NULL|NULL} ]
  [PRIMARY KEY]

table_constraints:
  [{INDEX|KEY} [index_name] (column_name|column_name->'$.json_path'|column_name->'$[*]')][,...]
  [FULLTEXT [INDEX|KEY] [index_name] (column_name) [index_option]] [,...]
  [PRIMARY KEY [index_name] (column_name,...)]
  [CLUSTERED KEY [index_name] (column_name[ASC|DESC],...) ]
  [[CONSTRAINT [symbol]] FOREIGN KEY (fk_column_name) REFERENCES pk_table_name (pk_column_name)][,...]
  [ANN INDEX [index_name] (column_name,...) [index_option]] [,...]

table_attribute:
  DISTRIBUTED BY HASH(column_name,...) | DISTRIBUTED BY BROADCAST

partition_options:
  PARTITION BY 
        {VALUE(column_name) | VALUE(DATE_FORMAT(column_name, 'format')) | VALUE(FROM_UNIXTIME(column_name, 'format'))}
  LIFECYCLE N
  
 index_all:
 INDEX_ALL= 'Y|N'

storage_policy:
  STORAGE_POLICY= {'HOT'|'COLD'|'MIXED' {hot_partition_count=N}}

block_size:
  BLOCK_SIZE= VALUE

engine:
  ENGINE= 'XUANWU|XUANWU_V2'
Catatan

Tabel internal di AnalyticDB for MySQL menggunakan algoritma kompresi zstd secara default.

Parameter

Parameter

Parameter

Deskripsi

table_name

Nama tabel harus terdiri dari 1 hingga 127 karakter, dimulai dengan huruf atau garis bawah (_), serta hanya boleh berisi huruf, angka, dan garis bawah (_).

Gunakan format db_name.table_name untuk membuat tabel di database tertentu.

column_name

Nama kolom harus terdiri dari 1 hingga 127 karakter, dimulai dengan huruf atau garis bawah (_), serta hanya boleh berisi huruf, angka, dan garis bawah (_).

column_type

Tipe data kolom. Untuk tipe data yang didukung oleh AnalyticDB for MySQL, lihat Tipe data dasar dan Tipe data kompleks.

COMMENT

Komentar untuk kolom atau tabel.

Atribut kolom

DEFAULT {constant | CURRENT_TIMESTAMP}

Menetapkan nilai default untuk kolom. Anda dapat menentukan konstanta atau menggunakan fungsi CURRENT_TIMESTAMP. Fungsi dan ekspresi variabel lain tidak didukung.

Jika Anda tidak menentukan nilai default, nilai default kolom tersebut adalah NULL.

AUTO_INCREMENT

Mendefinisikan kolom auto-increment. Tipe data kolom auto-increment harus berupa BIGINT.

AnalyticDB for MySQL memberikan nilai unik pada kolom auto-increment. Namun, nilai-nilai tersebut tidak dijamin berurutan dan mungkin tidak dimulai dari 1.

Penting
  • Saat memasukkan data ke dalam tabel yang berisi kolom auto-increment, tentukan nama kolom secara eksplisit dalam pernyataan tersebut. Contoh: INSERT INTO tabel (kolom1,kolom2) VALUES (nilai1,nilai2). Praktik ini mencegah error seperti Insert query has mismatched column sizes yang disebabkan oleh ketidaksesuaian jumlah atau urutan kolom.

  • Pada sistem terdistribusi, saat menulis data dengan pernyataan INSERT INTO SELECT, fitur auto-increment hanya menjamin nilai unik dalam satu proses ETL.

Kendala kolom

NOT NULL

Untuk kolom yang didefinisikan sebagai NOT NULL, nilainya tidak boleh NULL. Jika kolom tidak didefinisikan sebagai NOT NULL atau didefinisikan sebagai NULL, nilainya dapat berupa NULL.

PRIMARY KEY

Saat didefinisikan sebagai kendala kolom, kunci primer berlaku untuk satu kolom saja, misalnya id BIGINT NOT NULL PRIMARY KEY. Untuk membuat kunci primer gabungan dari beberapa kolom, Anda harus mendefinisikannya sebagai kendala tabel.

Kendala tabel (indeks)

AnalyticDB for MySQL mendukung berbagai jenis indeks, termasuk indeks biasa (INDEX), indeks kunci primer, indeks terkluster, indeks kunci asing, indeks teks penuh, dan indeks vektor. Sebuah tabel dapat memiliki satu atau lebih indeks.

INDEX | KEY

Mendefinisikan indeks biasa. INDEX dan KEY bersinonim.

  • Untuk tabel XUANWU_V2, indeks tidak dibuat pada semua kolom secara default. Jika tabel memiliki kunci primer, indeks biasa hanya dibuat secara default pada kunci tersebut.

  • Untuk tabel XUANWU, sistem membuat indeks pada semua kolom secara default. Namun, jika Anda membuat indeks secara manual pada kolom tertentu (misalnya, INDEX (id)) saat membuat tabel XUANWU, AnalyticDB for MySQL tidak akan membuat indeks secara otomatis pada kolom lain di tabel tersebut.

Catatan: Indeks gabungan tidak didukung. Misalnya, sintaksis INDEX (column1,column2) tidak didukung.

PRIMARY KEY

Mendefinisikan indeks kunci primer.

Penggunaan dasar

  • Setiap tabel hanya dapat memiliki satu kunci primer.

  • Kunci primer dapat terdiri dari satu kolom, seperti PRIMARY KEY (id), atau beberapa kolom, seperti PRIMARY KEY (id,name).

  • Kunci primer harus mencakup kunci distribusi dan kunci partisi. Tempatkan kunci distribusi dan kunci partisi di awal definisi kunci primer.

Catatan

  • Anda tidak dapat melakukan operasi DELETE dan UPDATE pada tabel yang tidak memiliki kunci primer.

  • Jika Anda tidak mendefinisikan kunci primer, perilaku berikut berlaku:

    • Jika Anda tidak mendefinisikan kunci primer dan kunci distribusi, AnalyticDB for MySQL secara otomatis menambahkan kolom bernama __adb_auto_id__ dan menggunakannya sebagai kunci primer sekaligus kunci distribusi.

    • Jika Anda mendefinisikan kunci distribusi tetapi tidak mendefinisikan kunci primer, AnalyticDB for MySQL tidak secara otomatis menambahkan kunci primer.

  • Setelah tabel dibuat, Anda tidak dapat menambah, menghapus, atau mengubah kolom kunci primer.

Rekomendasi penyetelan: Untuk kinerja yang lebih baik, gunakan kolom numerik untuk kunci primer dan minimalkan jumlah kolom dalam kunci tersebut.

Catatan

Terlalu banyak kolom dalam kunci primer dapat menyebabkan masalah berikut:

  • Peningkatan konsumsi resource CPU dan I/O karena AnalyticDB for MySQL memeriksa nilai kunci primer duplikat selama penulisan data.

  • Peningkatan penggunaan disk space oleh indeks kunci primer. Anda dapat menggunakan fitur Storage Analysis untuk melihat disk space yang digunakan oleh indeks kunci primer.

  • Job BUILD yang lebih lambat.

CLUSTERED KEY

Mendefinisikan indeks terkluster. Indeks terkluster dikonfigurasi di tingkat partisi dan menentukan urutan penyimpanan fisik data. Di dalam setiap partisi, data diurutkan berdasarkan nilai kunci indeks terkluster dan disimpan secara berurutan, secara default dalam urutan ascending. Sistem menyimpan data dengan nilai kunci yang sama atau mirip dalam blok data yang sama atau berdekatan. Untuk kueri rentang atau penyaringan kesetaraan, jika kondisi kueri sesuai dengan kolom indeks terkluster, mesin penyimpanan dapat membaca blok data berurutan dengan cepat. Hal ini mengurangi I/O disk dan meningkatkan kecepatan pembacaan data.

Diagram indeks terkluster

Skenario

Indeks terkluster cocok untuk kueri rentang maupun penyaringan kesetaraan. Pertimbangkan untuk membuat indeks terkluster pada kolom yang sering digunakan dalam kondisi kueri rentang atau penyaringan kesetaraan.

Saat kondisi kueri sepenuhnya atau sebagian sesuai dengan kolom indeks terkluster, efisiensi pembacaan data meningkat. Misalnya, dalam aplikasi SaaS di mana pengguna biasanya hanya mengakses datanya sendiri, Anda dapat menggunakan ID pengguna sebagai kunci indeks terkluster. Hal ini memastikan bahwa data untuk pengguna yang sama disimpan secara berurutan dalam blok data yang sama atau berdekatan, sehingga menghasilkan pembacaan data yang lebih cepat.

Penggunaan dasar

  • Setiap tabel hanya dapat memiliki satu indeks terkluster.

  • Anda dapat membuat indeks terkluster pada satu kolom, seperti CLUSTERED KEY index(id), atau pada beberapa kolom, seperti CLUSTERED KEY index(id,name). Saat indeks terkluster terdiri dari beberapa kolom, sistem pertama-tama mengurutkan data berdasarkan nilai di kolom pertama. Untuk baris dengan nilai yang sama di kolom pertama, data kemudian diurutkan berdasarkan nilai di kolom kedua. Oleh karena itu, CLUSTERED KEY index(id,name) berbeda dari CLUSTERED KEY index(name,id).

  • Secara default, indeks terkluster mengurutkan data dalam urutan ascending dan cocok untuk kueri ascending. Jika kueri Anda memerlukan urutan descending, atur indeks terkluster ke urutan descending saat membuat tabel, misalnya CLUSTERED KEY index(id) DESC. Jika tabel sudah ada, Anda dapat menghapus indeks terkluster yang ada lalu membuat yang baru dalam urutan descending.

  • Jangan gunakan kolom dengan nilai panjang, seperti string berukuran puluhan kilobyte, sebagai kunci indeks terkluster karena hal ini dapat menurunkan kinerja pengurutan.

FULLTEXT INDEX | FULLTEXT KEY

Mendefinisikan indeks teks penuh.

Sintaksis dan parameter

Sintaksis: [FULLTEXT [INDEX|KEY] [index_name] (column_name) [index_option]] [,...]

Parameter

FOREIGN KEY

Gunakan indeks kunci asing untuk menghilangkan join yang tidak perlu.

Sintaksis dan parameter

Persyaratan versi

Kluster AnalyticDB for MySQL Anda harus menjalankan versi kernel 3.1.10 atau lebih baru.

Catatan

Untuk melihat dan memperbarui versi minor, buka bagian Configuration Information pada halaman Cluster Information di Konsol AnalyticDB for MySQL.

Sintaksis: [[CONSTRAINT [symbol]] FOREIGN KEY (fk_column_name) REFERENCES pk_table_name (pk_column_name)][,...]

Parameter

  • symbol: Opsional. Nama kendala kunci asing, yang harus unik dalam tabel. Jika Anda tidak menentukan nama, parser secara otomatis menambahkan akhiran _fk ke nama kolom kunci asing dan menggunakan hasilnya sebagai nama kendala.

  • fk_column_name: Nama kolom kunci asing. Kolom ini harus didefinisikan dalam pernyataan pembuatan tabel.

  • pk_table_name: Nama tabel primer yang dirujuk. Tabel ini harus sudah ada.

  • pk_column_name: Nama kolom kunci primer di tabel primer yang dirujuk.

Penggunaan dasar

  • Setiap tabel dapat memiliki beberapa indeks kunci asing.

  • Indeks kunci asing gabungan tidak didukung. Misalnya, sintaksis FOREIGN KEY (sr_item_sk, sr_ticket_number) REFERENCES store_sales(ss_item_sk,d_date_sk) tidak didukung.

  • AnalyticDB for MySQL tidak melakukan pemeriksaan kendala data. Anda harus memastikan kendala data antara kunci primer tabel induk dan kunci asing tabel anak.

  • Anda tidak dapat membuat kendala kunci asing pada tabel eksternal.

ANN INDEX

Mendefinisikan indeks vektor.

Catatan: Anda tidak dapat membuat indeks vektor pada tabel XUANWU_V2.

Sintaksis dan parameter

Sintaksis: [ANN INDEX [index_name] (column_name,...) [index_option]] [,...]

Parameter

  • index_name: Nama indeks vektor.

  • column_name: Nama kolom vektor. Tipe datanya harus berupa array<float>, array<smallint>, atau array<byte>, dan Anda harus menentukan dimensinya. Contoh: feature array<float>(4).

  • index_option: Properti indeks vektor.

    • algorithm: Algoritma untuk perhitungan jarak vektor. Hanya HNSW_PQ yang didukung. Algoritma ini cocok untuk dataset berukuran sedang yang berisi jutaan hingga puluhan juta catatan per tabel dan sensitif terhadap dimensi vektor.

    • dis_function: Rumus untuk perhitungan jarak vektor. Hanya SquaredL2 yang didukung. Rumus: (x1-y1)^2+(x2-y2)^2+….

JSON INDEX

Mendefinisikan indeks JSON atau indeks array JSON.

Sintaksis dan parameter

Indeks JSON

Persyaratan versi

    Catatan

    Untuk melihat dan memperbarui versi minor, buka bagian Configuration Information pada halaman Cluster Information di Konsol AnalyticDB for MySQL.

    Sintaksis: [INDEX [index_name] (column_name|column_name->'$.json_path')]

    Parameter

    • index_name: Nama indeks.

    • column_name|column_name->'$.json_path':

      Indeks array JSON

      Persyaratan versi

      Hanya kluster yang menjalankan versi kernel 3.1.10.6 atau lebih baru yang mendukung indeks array JSON.

      Catatan

      Untuk melihat dan memperbarui versi minor, buka bagian Configuration Information pada halaman Cluster Information di Konsol AnalyticDB for MySQL.

      Sintaksis: [INDEX [index_name] (column_name->'$[*]')]

      Parameter

      • index_name: Nama indeks.

      • column_name->'$[*]': Kolom tempat membuat indeks array JSON. Misalnya, vj->'$[*]' membuat indeks array JSON pada kolom vj.

      Atribut tabel (kunci distribusi)

      table_attribute menentukan apakah tabel merupakan tabel standar atau tabel replikasi.

      • DISTRIBUTED BY HASH: Menentukan bahwa tabel adalah tabel standar. Tabel standar memanfaatkan sistem terdistribusi untuk meningkatkan efisiensi kueri. Tabel ini dapat menyimpan data dalam jumlah besar, biasanya dari puluhan juta hingga ratusan miliar baris.

      • DISTRIBUTED BY BROADCAST: Menentukan bahwa tabel adalah tabel replikasi. Tabel replikasi menyimpan salinan lengkap datanya di setiap shard dalam kluster. Kami merekomendasikan agar setiap tabel replikasi berisi tidak lebih dari 20.000 baris.

      DISTRIBUTED BY HASH (column_name,...)

      Menentukan kunci distribusi tabel. Tabel standar dengan kunci distribusi dikenal sebagai tabel partisi. AnalyticDB for MySQL menerapkan fungsi hash pada nilai kunci distribusi dan mendistribusikan baris ke shard berbeda berdasarkan nilai hash yang dihasilkan. Pendekatan ini meningkatkan skalabilitas dan kinerja kueri.

      Contoh sharding

      Penggunaan dasar

      • Setiap tabel hanya dapat memiliki satu kunci distribusi.

      • Kunci distribusi dapat terdiri dari satu atau beberapa kolom.

      • Kolom dalam kunci distribusi harus disertakan dalam kunci primer. Misalnya, jika kunci distribusi adalah customerid, kunci primer juga harus mencakup customerid.

      Catatan penggunaan

      • Jika Anda tidak menentukan kunci distribusi saat membuat tabel, sistem menanganinya sebagai berikut berdasarkan apakah tabel memiliki kunci primer:

        • Jika tabel memiliki kunci primer, AnalyticDB for MySQL menggunakan kunci primer sebagai kunci distribusi secara default.

        • Jika tabel tidak memiliki kunci primer, AnalyticDB for MySQL secara otomatis menambahkan kolom bernama __adb_auto_id__ dan menggunakannya sebagai kunci primer sekaligus kunci distribusi.

      • Setelah tabel dibuat, Anda tidak dapat menambah, menghapus, atau mengubah kolom kunci distribusi. Untuk memodifikasi kunci distribusi, buat tabel baru dan migrasikan datanya.

      Rekomendasi

      • Gunakan kolom sesedikit mungkin untuk kunci distribusi agar lebih serbaguna untuk berbagai kueri kompleks.

      • Pilih kolom yang sering digunakan dalam kondisi kueri dan memiliki kardinalitas tinggi (nilai terdistribusi merata) sebagai kunci distribusi. Contoh yang baik termasuk ID transaksi, ID perangkat, ID pengguna, atau kolom auto-increment. Namun, hindari kolom yang selalu difilter dengan nilai konstan. Misalnya, jika kolom a sering dikueri tetapi kondisinya selalu a=3, menggunakannya sebagai kunci distribusi akan menyebabkan kesenjangan data, sehingga menjadi pilihan yang tidak tepat.

      • Gunakan kolom yang digunakan untuk join sebagai kunci distribusi. Saat dua tabel di-join, jika keduanya memiliki kunci distribusi yang sama (kolom join), data dengan nilai kunci yang sama ditempatkan bersama di shard yang sama. Hal ini memungkinkan operasi join dilakukan secara lokal tanpa memindahkan data antar shard, mengurangi redistribusi data dan meningkatkan kinerja kueri. Misalnya, jika Anda perlu melihat riwayat pesanan berdasarkan pelanggan, Anda dapat memilih customer_id sebagai kunci distribusi.

      • Hindari menggunakan kolom tanggal, waktu, atau stempel waktu sebagai kunci distribusi. Kolom-kolom ini dapat menyebabkan kesenjangan data selama penulisan dan mengurangi kinerja penulisan. Selain itu, kueri sering difilter berdasarkan rentang tanggal atau waktu tertentu. Jika kolom berbasis waktu adalah kunci distribusi, semua data untuk kueri mungkin berada di satu node, mencegah kueri diproses secara paralel di seluruh kluster. Kami merekomendasikan agar Anda menggunakan kolom tanggal dan waktu sebagai kunci partisi sebagai gantinya.

      • Anda dapat menggunakan fitur diagnostik penyimpanan untuk memeriksa apakah kunci distribusi efektif dan mengidentifikasi kesenjangan data.

      DISTRIBUTED BY BROADCAST

      Menentukan tabel replikasi. Tabel replikasi menyimpan salinan lengkap datanya di setiap shard kluster. Kami merekomendasikan agar Anda tidak menyimpan data dalam jumlah besar di tabel replikasi.

      Keuntungan: Selama operasi join, data dari tabel replikasi tidak perlu dipindahkan antar shard. Dalam skenario konkurensi tinggi, hal ini dapat secara signifikan mengurangi overhead jaringan dan meningkatkan stabilitas kluster.

      Kerugian: Saat data di tabel replikasi diubah (karena operasi INSERT, UPDATE, atau DELETE), perubahan tersebut disiarkan ke semua shard untuk memastikan konsistensi data di semua salinan. Hal ini berdampak pada kinerja penulisan secara keseluruhan, sehingga kami merekomendasikan untuk menghindari modifikasi yang sering pada tabel replikasi.

      Kunci partisi dan siklus hidup

      Jika sebuah shard berisi data dalam jumlah besar setelah menetapkan kunci distribusi, Anda dapat mendefinisikan kunci partisi untuk membagi data di shard tersebut menjadi partisi. Hal ini mempercepat penyaringan data dan meningkatkan kinerja kueri.

      Mengapa mendefinisikan partisi?

      • Partisi mempercepat penyaringan data dan meningkatkan kinerja kueri.

        • Pemangkasan partisi. Kueri hanya memindai partisi yang relevan dan melewati partisi yang tidak relevan. Hal ini mengurangi jumlah data yang dipindai dan meningkatkan kecepatan kueri.

        • Peningkatan kinerja pemindaian indeks. Efisiensi pemindaian indeks menurun jika indeks mencakup terlalu banyak baris, misalnya lebih dari 50 juta. Indeks bersifat tingkat partisi, artinya setiap partisi memiliki indeks independennya sendiri. Jika tabel tidak dipartisi, semua datanya berada dalam satu partisi. Saat volume data melebihi puluhan juta baris, efisiensi pemindaian indeks turun. Memartisi tabel mendistribusikan data ke partisi di shard berbeda. Hal ini memungkinkan Anda mengontrol jumlah baris dalam indeks setiap partisi, menjaganya dalam kisaran puluhan juta untuk memastikan kinerja pemindaian optimal.

        • Peningkatan efisiensi BUILD. Operasi BUILD mengonversi data real-time menjadi data historis. Proses ini melibatkan pembuatan partisi, pembuatan indeks, dan pembersihan data redundan. Indeks baru hanya berlaku setelah operasi BUILD selesai. Jika tabel tidak dipartisi, setiap operasi BUILD memproses seluruh tabel. Semakin besar tabel, semakin lama operasi BUILD berlangsung, menunda aktivasi indeks baru dan menurunkan kinerja kueri. Saat tabel dipartisi, operasi BUILD hanya berjalan pada partisi yang mengalami perubahan data, sehingga mempersingkat waktu BUILD.

      • Anda dapat menggunakan partisi dengan klausa LIFECYCLE untuk mengelola siklus hidup data.

      • Anda dapat menggunakan partisi dengan kebijakan penyimpanan (storage_policy) untuk mengjenjangkan data hot dan cold.

      Partisi data dan manajemen siklus hidup

      PARTITION BY

      Menentukan kunci partisi.

      Sintaksis: PARTITION BY VALUE {(column_name)|(DATE_FORMAT(column_name, 'format'))|(FROM_UNIXTIME(column_name, 'format'))} LIFECYCLE n

      Parameter:

      • column_name: Kunci partisi. PARTITION BY VALUE(column_name) menunjukkan bahwa nilai dalam kolom column_name digunakan untuk mempartisi data. Tipe data kunci partisi dapat berupa tipe numerik, tipe datetime, atau string yang merepresentasikan angka.

      • DATE_FORMAT(column_name, 'format')|FROM_UNIXTIME(column_name, 'format'): Menggunakan fungsi DATE_FORMAT atau FROM_UNIXTIME untuk mengonversi kolom datetime ke format tanggal tertentu untuk partisi. Parameter format hanya mendukung format tahun, bulan, dan hari, seperti %Y, %y, %Y%m, %y%m, %Y%m%d, dan %y%m%d. Setelah pembuatan tabel, Anda dapat memodifikasi format menggunakan pernyataan ALTER TABLE.

        • Gunakan fungsi DATE_FORMAT saat kolom bertipe BIGINT, TIMESTAMP, DATETIME, atau VARCHAR. Untuk kolom BIGINT, nilainya harus berupa stempel waktu UNIX tingkat milidetik, seperti 1734278400000. Untuk kolom TIMESTAMP, DATETIME, dan VARCHAR, nilainya harus dalam format seperti "2024-11-26 00:01:02".

        • Gunakan fungsi FROM_UNIXTIME saat kolom bertipe INT. Nilainya harus berupa stempel waktu UNIX tingkat detik, seperti 1696266000.

      Catatan penggunaan

      • Untuk kluster dengan versi kernel sebelum 3.2.1.0, saat Anda menggunakan PARTITION BY untuk menentukan partisi, Anda juga harus menentukan siklus hidup (LIFECYCLE n). Jika tidak, terjadi error.

      • Untuk kluster dengan versi kernel 3.2.1.0 atau lebih baru, saat Anda menggunakan PARTITION BY untuk menentukan partisi, siklus hidup (LIFECYCLE n) bersifat opsional. Jika Anda menghilangkan parameter ini, sistem tidak membersihkan data partisi.

      • Setelah tabel dibuat, Anda tidak dapat menambahkan kunci partisi, atau menambah, menghapus, atau memodifikasi kolom dalam kunci partisi. Untuk menambah atau memodifikasi kunci partisi, Anda harus membuat tabel baru dan migrasikan datanya. Untuk informasi lebih lanjut, lihat ALTER TABLE.

      Rekomendasi

      • Kami merekomendasikan agar Anda menggunakan bidang bertipe datetime sebagai kunci partisi.

      • Partisi yang terlalu besar atau terlalu kecil dapat menurunkan kinerja kueri dan penulisan, bahkan berdampak pada stabilitas kluster. Untuk rekomendasi tentang jumlah baris per partisi dan cara memvalidasi strategi partisi Anda, lihat Diagnosa tabel partisi.

      • Hindari pembaruan data yang sering pada partisi historis. Misalnya, jika Anda sering memperbarui beberapa partisi historis setiap hari, Anda harus mengevaluasi kembali apakah kunci partisi Anda sudah tepat.

      LIFECYCLE n

      Gunakan klausa LIFECYCLE dengan PARTITION BY untuk mengelola siklus hidup partisi. AnalyticDB for MySQL mengurutkan partisi dalam urutan descending berdasarkan nilai kunci partisi, menyimpan n partisi teratas, dan menghapus partisi apa pun yang berada di luar rentang ini. Anda dapat menggunakan LIFECYCLE untuk menentukan periode retensi data.

      • Untuk versi kernel sebelum 3.2.1.1, LIFECYCLE n menentukan bahwa setiap shard dapat menyimpan maksimal n partisi. Saat mengelola siklus hidup partisi di tingkat shard, jumlah total partisi yang disimpan mungkin melebihi n jika data tidak terdistribusi merata atau volume datanya sangat kecil.

      • Untuk versi kernel 3.2.1.1 dan lebih baru, untuk tabel yang menggunakan mesin XUANWU: Tabel baru yang dibuat setelah upgrade menggunakan manajemen siklus hidup tingkat tabel, di mana LIFECYCLE n menentukan bahwa setiap tabel menyimpan maksimal n partisi. Tabel yang dibuat sebelum upgrade tetap menggunakan manajemen siklus hidup tingkat shard, di mana LIFECYCLE n menentukan bahwa setiap shard menyimpan maksimal n partisi.

      • Tabel yang menggunakan mesin XUANWU_V2 tetap menggunakan manajemen siklus hidup tingkat shard, di mana LIFECYCLE n menentukan bahwa setiap shard menyimpan maksimal n partisi. Mesin XUANWU_V2 belum mendukung manajemen siklus hidup tingkat tabel.

      Contoh

      Klausa PARTITION BY VALUE (DATE_FORMAT(date, '%Y%m%d')) LIFECYCLE 30 mempartisi data dengan mengonversi kolom date ke format yyyyMMdd dan menyimpan maksimal 30 partisi. Misalkan data hari ke-1 ditulis ke partisi 20231201, data hari ke-2 ke partisi 20231202, dan seterusnya, hingga data hari ke-30 ditulis ke partisi 20231230. Saat data hari ke-31 ditulis ke partisi 20231231, partisi terlama (20231201) secara otomatis dihapus untuk mempertahankan maksimal 30 partisi.

      index_all

      Menentukan apakah akan membuat indeks pada semua kolom.

      Nilai yang valid:

      • Y: Membuat indeks pada semua kolom. Nilai default untuk tabel XUANWU adalah Y.

      • N: Membuat indeks hanya pada kunci primer. Nilai default untuk tabel XUANWU_V2 adalah N.

      storage_policy

      Untuk kluster Edisi Perusahaan, Edisi Dasar, dan Edisi Data Lakehouse serta kluster Edisi Gudang Data dalam mode elastis (baru), Anda dapat menentukan kebijakan penyimpanan. Kebijakan penyimpanan yang berbeda menawarkan tingkat kinerja baca/tulis dan biaya penyimpanan yang berbeda.

      Nilai yang valid:

      • hot (default): penyimpanan hot. Kebijakan ini menyimpan semua partisi tabel di SSD. Kebijakan ini memberikan kinerja terbaik dengan biaya penyimpanan tertinggi.

      • cold: penyimpanan cold. Kebijakan ini menyimpan semua partisi tabel di Object Storage Service (OSS). Dibandingkan dengan penyimpanan hot, kebijakan ini menawarkan kinerja lebih rendah dengan biaya penyimpanan terendah.

      • mixed: penyimpanan berjenjang. Kebijakan ini menyeimbangkan biaya penyimpanan dengan kinerja kueri dengan menyimpan data yang sering diakses (data hot) di SSD dan data yang jarang diakses (data cold) di OSS. Untuk menggunakan kebijakan mixed, Anda harus mendefinisikan partisi dengan klausa PARTITION BY dan menentukan jumlah partisi hot dengan parameter hot_partition_count. Jika tidak ada partisi yang didefinisikan, kebijakan mixed tidak berpengaruh, dan sistem menyimpan semua data di SSD.

        Diagram Penyimpanan Berjenjang

      hot_partition_count

      Saat STORAGE_POLICY='mixed' ditetapkan, gunakan hot_partition_count=n (di mana n adalah bilangan bulat positif) untuk menentukan jumlah partisi hot. AnalyticDB for MySQL mengurutkan semua partisi dalam urutan descending berdasarkan nilai kunci partisinya. Partisi n terbesar adalah partisi hot, dan sisanya adalah partisi cold.

      Catatan

      Anda tidak dapat menentukan hot_partition_count=n jika STORAGE_POLICY bukan 'mixed'. Jika Anda mencoba melakukannya, sistem akan mengembalikan error.

      BLOCK_SIZE

      Blok data adalah unit I/O minimum untuk pembacaan dan penulisan data. Parameter BLOCK_SIZE menentukan jumlah baris yang terdapat dalam setiap blok data pada penyimpanan berorientasi kolom. Menyesuaikan nilai ini mengubah jumlah baris yang dibaca per operasi I/O, dan dampaknya terhadap kinerja bergantung pada pola kueri Anda. Misalnya, untuk kueri titik, BLOCK_SIZE yang besar dapat mengurangi efisiensi baca karena sistem harus membaca seluruh blok meskipun hanya mengambil beberapa baris. Dalam kasus ini, Anda dapat meningkatkan kinerja dengan mengatur BLOCK_SIZE yang lebih kecil.

      Nilai default:

      • 4096: Nilai default untuk tabel replikasi.

      • 8192: Nilai default untuk edisi kluster baru dalam mode elastis dan untuk Edisi Standalone dengan kurang dari 32 core komputasi.

      • 32760: Nilai default dalam semua kasus lain. Saat nilai default ini digunakan, pernyataan SHOW CREATE TABLE tidak menampilkan pengaturan BLOCK_SIZE.

      Penting

      Jika Anda tidak familiar dengan prinsip penyimpanan berorientasi kolom, hindari mengubah nilai BLOCK_SIZE.

      Engine

      Menentukan mesin penyimpanan untuk tabel internal di AnalyticDB for MySQL yang digunakan untuk analisis data historis.

      • Untuk versi kernel sebelum 3.2.2.0, nilainya adalah XUANWU. Ini adalah nilai default jika Anda tidak menentukan ENGINE saat membuat tabel.

        Penting

        Untuk versi kernel sebelum 3.1.9.5, jika Anda secara eksplisit menentukan ENGINE='XUANWU' saat membuat tabel internal, Anda juga harus secara eksplisit menentukan table_properties='{"format":"columnstore"}'. Jika tidak, pembuatan tabel gagal.

      • Untuk versi kernel 3.2.2.0 dan lebih baru, nilai yang valid adalah sebagai berikut:

        • Jika RC_DDL_ENGINE_REWRITE_XUANWUV2 diatur ke true, nilainya harus XUANWU_V2.

        • Jika RC_DDL_ENGINE_REWRITE_XUANWUV2 diatur ke false, Anda dapat menggunakan XUANWU_V2 atau XUANWU.

        Anda dapat menjalankan perintah SHOW ADB_CONFIG KEY=RC_DDL_ENGINE_REWRITE_XUANWUV2; untuk memeriksa nilai parameter ini. Anda juga dapat memodifikasi nilai RC_DDL_ENGINE_REWRITE_XUANWUV2 di tingkat kluster atau tingkat tabel.

      CTAS

      Pernyataan CREATE TABLE AS query_expr membuat dan mengisi tabel dengan set hasil dari kueri SELECT. Untuk penggunaan terperinci, lihat CREATE TABLE AS SELECT (CTAS).

      Contoh

      Partisi otomatis berdasarkan tanggal

      Buat tabel partisi bernama sales yang secara otomatis dipartisi berdasarkan tanggal di kolom sale_time.

      CREATE TABLE sales (
        sale_id BIGINT NOT NULL COMMENT 'ID Pesanan',
        customer_id VARCHAR NOT NULL COMMENT 'ID Pelanggan',
        phone_num BIGINT NOT NULL COMMENT 'Nomor telepon pelanggan',
        revenue DECIMAL(15, 2) COMMENT 'Jumlah pesanan',
        sale_time TIMESTAMP NOT NULL COMMENT 'Waktu pesanan',
        PRIMARY KEY (sale_time,sale_id)
       )
      DISTRIBUTED BY HASH(sale_id)
      PARTITION BY VALUE(DATE_FORMAT(sale_time, '%Y%m%d'));                   

      Tabel partisi dengan siklus hidup

      Buat tabel partisi bernama customer. Kolom login_time, customer_id, dan phone_num membentuk kunci primer gabungan. kunci distribusi adalah customer_id, kunci partisi adalah login_time, dan siklus hidup diatur ke 30.

      Partisi diurutkan dalam urutan descending berdasarkan kunci partisi login_time (misalnya, 20231202, 20231201). Sistem hanya menyimpan 30 partisi dengan nilai kunci terbesar. Saat data ditulis ke partisi ke-31, sistem secara otomatis menghapus partisi dengan nilai kunci terkecil.

      Misalnya, asumsikan data ditulis dengan login_time 20231201 pada hari ke-1, 20231202 pada hari ke-2, dan seterusnya. Saat data dengan login_time 20231231 ditulis pada hari ke-31, sistem secara otomatis menghapus partisi dengan data terlama ('20231201'). Hal ini mempertahankan hanya data dari 30 hari terakhir.

      CREATE TABLE customer (
        customer_id BIGINT NOT NULL COMMENT 'ID Pelanggan',
        customer_name VARCHAR NOT NULL COMMENT 'Nama pelanggan',
        phone_num BIGINT NOT NULL COMMENT 'Nomor telepon',
        city_name VARCHAR NOT NULL COMMENT 'Kota',
        sex INT NOT NULL COMMENT 'Jenis kelamin',
        id_number VARCHAR NOT NULL COMMENT 'Nomor KTP',
        home_address VARCHAR NOT NULL COMMENT 'Alamat rumah',
        office_address VARCHAR NOT NULL COMMENT 'Alamat kantor',
        age INT NOT NULL COMMENT 'Usia',
        login_time TIMESTAMP NOT NULL COMMENT 'Waktu login',
        PRIMARY KEY (login_time,customer_id,phone_num)
       )
      DISTRIBUTED BY HASH(customer_id)
      PARTITION BY VALUE(DATE_FORMAT(login_time, '%Y%m%d')) LIFECYCLE 30
      COMMENT 'Tabel informasi pelanggan';                   

      Tabel non-partisi

      Perilaku default: Kunci primer sebagai kunci distribusi

      Jika Anda mendefinisikan kunci primer untuk tabel tetapi tidak menentukan kunci distribusi, AnalyticDB for MySQL menggunakan kunci primer sebagai kunci distribusi secara default.

      CREATE TABLE orders (
        order_id BIGINT NOT NULL COMMENT 'ID Pesanan',
        customer_id INT NOT NULL COMMENT 'ID Pelanggan',
        order_status VARCHAR(1) NOT NULL COMMENT 'Status pesanan',
        total_price DECIMAL(15, 2) NOT NULL COMMENT 'Jumlah pesanan',
        order_date DATE NOT NULL COMMENT 'Tanggal pesanan',
        PRIMARY KEY(order_id,order_date)
      );

      Jalankan pernyataan SHOW CREATE TABLE untuk memverifikasi hasilnya. Output menunjukkan bahwa kolom kunci primer order_id dan order_date juga berfungsi sebagai kunci distribusi.

      SHOW CREATE TABLE orders;
      +---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
      | Table   | Create Table                                                                                                                                  | 
      +---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
      | orders  | CREATE TABLE `orders` (                                                                                                                       |
      |         | `order_id` bigint NOT NULL COMMENT 'ID Pesanan',                                                                                                   |
      |         | `customer_id` int NOT NULL COMMENT 'ID Pelanggan',                                                                                                   |
      |         | `order_status` varchar(1) NOT NULL COMMENT 'Status pesanan',                                                                                         | 
      |         | `total_price` decimal(15, 2) NOT NULL COMMENT 'Jumlah pesanan',                                                                                      |
      |         | `order_date` date NOT NULL COMMENT 'Tanggal pesanan',                                                                                                 |
      |         | PRIMARY KEY (`order_id`,`order_date`)                                                                                                         |
      |         | ) DISTRIBUTED BY HASH(`order_id`,`order_date`) INDEX_ALL='Y' STORAGE_POLICY='HOT' ENGINE='XUANWU' TABLE_PROPERTIES='{"format":"columnstore"}'  |
      +---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
      1 row in set (0.04 sec)

      Perilaku default: Kunci primer dan distribusi ditambahkan otomatis

      Jika Anda membuat tabel tanpa menentukan kunci primer atau kunci distribusi, AnalyticDB for MySQL secara otomatis menambahkan kolom bernama __adb_auto_id__ dan menggunakannya sebagai kunci primer sekaligus kunci distribusi.

      CREATE TABLE orders_new (
        order_id BIGINT NOT NULL COMMENT 'ID Pesanan',
        customer_id INT NOT NULL COMMENT 'ID Pelanggan',
        order_status VARCHAR(1) NOT NULL COMMENT 'Status pesanan',
        total_price DECIMAL(15, 2) NOT NULL COMMENT 'Jumlah pesanan',
        order_date DATE NOT NULL COMMENT 'Tanggal pesanan'
      );

      Jalankan pernyataan SHOW CREATE TABLE untuk memverifikasi hasilnya. Output menunjukkan bahwa AnalyticDB for MySQL menambahkan kolom auto-increment bernama __adb_auto_id__ dan menetapkannya sebagai kunci primer sekaligus kunci distribusi.

      SHOW CREATE TABLE orders_new;
      +-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
      | Table       | Create Table                                                                                                                                  | 
      +-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
      | orders_new  | CREATE TABLE `orders_new` (                                                                                                                   |
      |             | `__adb_auto_id__` bigint AUTO_INCREMENT,                                                                                                      |
      |             | `order_id` bigint NOT NULL COMMENT 'ID Pesanan',                                                                                                   |
      |             | `customer_id` int NOT NULL COMMENT 'ID Pelanggan',                                                                                                   |
      |             | `order_status` varchar(1) NOT NULL COMMENT 'Status pesanan',                                                                                         | 
      |             | `total_price` decimal(15, 2) NOT NULL COMMENT 'Jumlah pesanan',                                                                                      |
      |             | `order_date` date NOT NULL COMMENT 'Tanggal pesanan',                                                                                                 |
      |             | PRIMARY KEY (`__adb_auto_id__`)                                                                                                               |
      |             | ) DISTRIBUTED BY HASH(`__adb_auto_id__`) INDEX_ALL='Y' STORAGE_POLICY='HOT' ENGINE='XUANWU' TABLE_PROPERTIES='{"format":"columnstore"}'        |
      +-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
      1 row in set (0.04 sec)

      Tentukan kunci primer dan distribusi

      Buat tabel bernama supplier. Kolom supplier_id adalah kolom auto-increment. kunci distribusi adalah supplier_id, dan data di-shard dengan meng-hash nilai supplier_id.

      CREATE TABLE supplier (
        supplier_id BIGINT AUTO_INCREMENT PRIMARY KEY,
        supplier_name VARCHAR,
        address INT,
        phone VARCHAR
      ) 
      DISTRIBUTED BY HASH(supplier_id);

      Kebijakan penyimpanan berjenjang

      Kebijakan Cold Storage

      CREATE TABLE item (
        order_id BIGINT NOT NULL,
        item_id INT NOT NULL,
        quantity DECIMAL(15, 2) NOT NULL,
        discount DECIMAL(15, 2) NOT NULL,
        shipdate DATE NOT NULL,
        PRIMARY KEY (order_id,item_id,shipdate)
      ) 
      DISTRIBUTED BY HASH(item_id) 
      PARTITION BY VALUE(date_format(shipdate, '%Y%m')) LIFECYCLE 200 
      STORAGE_POLICY='COLD';

      Kebijakan penyimpanan hot

      CREATE TABLE item (
        order_id BIGINT NOT NULL,
        item_id INT NOT NULL,
        quantity DECIMAL(15, 2) NOT NULL,
        discount DECIMAL(15, 2) NOT NULL,
        shipdate DATE NOT NULL,
        PRIMARY KEY (order_id,item_id,shipdate)
      ) 
      DISTRIBUTED BY HASH(item_id) 
      PARTITION BY VALUE(date_format(shipdate, '%Y%m')) LIFECYCLE 200 
      STORAGE_POLICY='HOT';

      Kebijakan campuran dengan 16 partisi hot

      CREATE TABLE item (
        order_id BIGINT NOT NULL,
        item_id INT NOT NULL,
        quantity DECIMAL(15, 2) NOT NULL,
        discount DECIMAL(15, 2) NOT NULL,
        shipdate DATE NOT NULL,
        PRIMARY KEY (order_id,item_id,shipdate)
      ) 
      DISTRIBUTED BY HASH(item_id) 
      PARTITION BY VALUE(date_format(shipdate, '%Y%m')) LIFECYCLE 200  
      STORAGE_POLICY='MIXED' HOT_PARTITION_COUNT=16;

      Buat indeks biasa pada kolom tertentu

      Contoh ini membuat indeks biasa pada kolom id dan date.

      CREATE TABLE index_tb (
        id INT,
        sales DECIMAL(15, 2),
        date DATE,
        INDEX (id),
        INDEX (date),
        PRIMARY KEY (id)
      ) 
      DISTRIBUTED BY HASH(id);

      Definisikan indeks terkluster

      Buat indeks terkluster bernama clustered_index pada kolom quantity.

      CREATE TABLE clustered (
        product_id INT,
        product_name VARCHAR,
        quantity INT,        
        price DECIMAL(10, 2),
        CLUSTERED KEY INDEX clustered_index(quantity)
      )
      DISTRIBUTED BY HASH(product_id);

      Indeks teks penuh

      Buat indeks teks penuh bernama fidx_c pada kolom content.

      CREATE TABLE fulltext_tb (
        id INT,
        content VARCHAR,
        keyword VARCHAR,
        FULLTEXT INDEX fidx_c(content),
        PRIMARY KEY (id)
      ) 
      DISTRIBUTED BY HASH(id);

      Untuk informasi lebih lanjut tentang membuat dan memodifikasi indeks teks penuh, lihat Buat indeks teks penuh.

      Untuk informasi lebih lanjut, lihat Pencarian teks penuh.

      Definisikan indeks vektor

      Definisikan short_feature (tipe array<smallint>) dan float_feature (tipe array<float>) sebagai kolom vektor dengan dimensi 4.

      Buat indeks vektor short_feature_index pada kolom short_feature dan float_feature_index pada kolom float_feature.

      CREATE TABLE fact_tb (  
        xid BIGINT NOT NULL,  
        cid BIGINT NOT NULL,  
        uid VARCHAR NOT NULL,  
        vid VARCHAR NOT NULL,  
        wid VARCHAR NOT NULL,  
        short_feature array<smallint>(4),  
        float_feature array<float>(4),  
        ann index short_feature_index(short_feature), 
        ann index float_feature_index(float_feature),  
        PRIMARY KEY (xid, cid, vid)
      ) 
      DISTRIBUTED BY HASH(xid) PARTITION BY VALUE(cid) LIFECYCLE 4;

      Untuk detail tentang pengindeksan vektor dan pencarian vektor, lihat Pencarian vektor.

      Definisikan kunci asing

      Buat tabel bernama store_returns. Gunakan klausa FOREIGN KEY untuk mengaitkan kolom sr_item_sk dengan kunci primer customer_id dari tabel customer.

      CREATE TABLE store_returns (
        sr_sale_id BIGINT NOT NULL PRIMARY KEY,
        sr_store_sk BIGINT,
        sr_item_sk BIGINT NOT NULL,
        FOREIGN KEY (sr_item_sk) REFERENCES customer (customer_id)
      );

      Indeks array JSON

      Buat indeks array JSON bernama idx_vj pada kolom vj.

      CREATE TABLE json(
        id INT,
        vj JSON,
        INDEX idx_vj(vj->'$[*]')
      )
      DISTRIBUTED BY HASH(id);

      Untuk detail tentang membuat dan memodifikasi indeks array JSON, lihat Buat indeks array JSON dan Indeks array JSON.

      FAQ

      Atribut dan kendala kolom

      Apakah nilai dalam kolom auto-increment dimulai dari 1? Apakah nilainya unik?

      Nilai dalam kolom auto-increment tidak berurutan dan tidak dimulai dari 1. Namun, nilainya dijamin unik.

      Kunci distribusi, kunci partisi, dan siklus hidup

      Apa perbedaan antara kunci distribusi dan kunci partisi?

      Data didistribusikan ke shard berdasarkan hash nilai kunci distribusi. Di dalam setiap shard, data selanjutnya dibagi menjadi partisi berdasarkan nilai kunci partisi. Diagram berikut menggambarkan proses ini.

      Haruskah saya menentukan kunci distribusi saat membuat tabel?

      • Menentukan kunci distribusi bersifat opsional saat membuat tabel partisi. Jika Anda tidak menentukan kunci distribusi, AnalyticDB for MySQL menggunakan kunci primer sebagai kunci distribusi. Jika tidak ada kunci primer yang ditentukan, sistem secara otomatis membuat kolom bernama __adb_auto_id__ dan menggunakannya sebagai kunci distribusi sekaligus kunci primer.

      • Anda tidak perlu menentukan kunci distribusi saat membuat tabel replikasi. Namun, Anda harus menentukan DISTRIBUTED BY BROADCAST untuk menunjukkan bahwa sistem menyimpan salinan lengkap data di setiap node penyimpanan.

      Apakah mengubah spesifikasi kluster mengubah jumlah shard?

      Tidak. Mengubah spesifikasi kluster tidak mengubah jumlah shard.

      Bagaimana cara mengkueri informasi partisi tabel?

      Untuk mengkueri informasi partisi tabel, jalankan pernyataan SQL berikut:

      SELECT partition_id, -- Nama partisi.
       row_count, -- Jumlah total baris dalam partisi.
       local_data_size, -- Ukuran penyimpanan lokal yang ditempati partisi.
       index_size, -- Ukuran indeks dalam partisi.
       pk_size, -- Ukuran indeks kunci primer dalam partisi.
       remote_data_size -- Ukuran penyimpanan jarak jauh yang ditempati partisi.
      FROM information_schema.kepler_partitions
      WHERE schema_name = '$DB'
       AND table_name ='$TABLE' 
       AND partition_id > 0;

      Mengapa saya tidak dapat menemukan informasi partisi setelah membuat tabel partisi?

      Masalah ini terjadi karena alasan berikut:

      • Saat membuat tabel, Anda hanya mendefinisikan aturan partisi dengan menentukan kunci partisi; sistem tidak segera membuat partisi. Sistem membuat partisi berdasarkan nilai kunci partisi. Jika Anda belum menulis data ke tabel, sistem tidak membuat partisi karena kunci partisi tidak memiliki nilai.

      • Pembuatan partisi bukan proses real-time. Anda hanya dapat melihat informasi partisi setelah job BUILD untuk data yang ditulis selesai.

      Solusi:

      Tulis data ke tabel dan tunggu hingga BUILD job selesai. Anda kemudian dapat melihat informasi partisi.

      Bagaimana cara mengkueri data di partisi tertentu?

      Anda dapat mengkueri data dari partisi tertentu dengan menggunakan kondisi filter WHERE <nama kunci partisi> = '<nilai kunci partisi>'. Penggunaan serupa, seperti SELECT * FROM tabel PARTITION(202304), tidak didukung.

      Contoh berikut menunjukkan cara mengkueri data di partisi tertentu.

      Tabel partisi bernama orders_demo dibuat dan dipartisi berdasarkan kolom order_date. Berikut adalah contoh pernyataan CREATE TABLE:

      CREATE TABLE orders_demo (
        order_id BIGINT NOT NULL COMMENT 'ID Pesanan',
        customer_id INT NOT NULL COMMENT 'ID Pelanggan',
        order_status VARCHAR(1) NOT NULL COMMENT 'Status pesanan',
        total_price DECIMAL(15, 2) NOT NULL COMMENT 'Jumlah pesanan',
        order_date DATE NOT NULL COMMENT 'Tanggal pesanan',
        PRIMARY KEY(order_id,order_date)
      )
      DISTRIBUTED BY HASH(order_id) 
      PARTITION BY VALUE(date_format(order_date, '%Y%m')) LIFECYCLE 30 ;

      Berikut adalah contoh kode untuk memasukkan 10 baris data ke tabel:

      INSERT INTO orders_demo (order_id, customer_id, order_status, total_price, order_date)
      VALUES
        (1001, 1, 'C', 150.75, '2023-10-01'),
        (1002, 2, 'P', 200.50, '2023-10-01'),
        (1003, 3, 'S', 99.99, '2023-10-01'),
        (1004, 4, 'C', 300.00, '2023-10-01'),
        (1005, 5, 'P', 450.25, '2023-10-02'),
        (1006, 6, 'S', 120.00, '2023-10-02'),
        (1007, 7, 'C', 80.50, '2023-10-03'),
        (1008, 8, 'P', 600.00, '2023-10-03'),
        (1009, 9, 'S', 250.75, '2023-10-03'),
        (1010, 10, 'C', 199.99, '2023-10-14');

      Berikut adalah contoh pernyataan untuk membangun secara manual tabel partisi untuk membuat partisi:

      BUILD TABLE orders_demo;
      Job BUILD dipicu secara otomatis saat tabel memenuhi kondisi tertentu. Dalam contoh ini, kami menjalankan job BUILD secara manual untuk memfasilitasi langkah-langkah selanjutnya. Untuk informasi lebih lanjut, lihat BUILD otomatis.

      Kueri status job BUILD. Jika field status mengembalikan FINISH, job BUILD untuk tabel orders_demo telah selesai.

      SELECT table_name, schema_name, status FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK WHERE table_name='ORDERS_DEMO';

      Dalam contoh ini, kunci partisi order_date bertipe DATE. Untuk mengkueri data di partisi untuk 2023-10-01, jalankan pernyataan SQL berikut:

      SELECT * FROM orders_demo WHERE order_date='2023-10-01';

      Jika kunci partisi bertipe DATETIME, Anda harus menentukan rentang waktu seperti WHERE order_date >= "2023-10-01 00:00:00" and order_date < "2023-10-02 00:00:00" untuk mengkueri data di partisi untuk 2023-10-01. Contoh pernyataan:

      SELECT * FROM orders_demo WHERE order_date >= "2023-10-01 00:00:00" and order_date < "2023-10-02 00:00:00";

      Saat mengkueri tabel partisi, haruskah saya menggunakan kunci partisi sebagai kondisi filter?

      Tidak. Namun, menggunakan kunci partisi sebagai kondisi filter secara signifikan meningkatkan kinerja kueri dengan memungkinkan sistem hanya memindai partisi yang relevan, bukan seluruh tabel.

      Apa persyaratan tipe data untuk kunci partisi?

      Kunci partisi harus bertipe numerik, tanggal/waktu, atau string yang merepresentasikan angka. Menggunakan tipe data lain dapat menyebabkan error penulisan data.

      Pesan error partition format function error menunjukkan bahwa nilai yang ditulis ke kunci partisi tidak memenuhi persyaratan tipe data.

      Dapatkah saya menggunakan fungsi selain DATE_FORMAT dan FROM_UNIXTIME untuk mendefinisikan kunci partisi?

      Tidak. Anda hanya dapat mendefinisikan kunci partisi dengan salah satu metode berikut: PARTITION BY VALUE(column), PARTITION BY VALUE(DATE_FORMAT(column,'format')), atau PARTITION BY VALUE(FROM_UNIXTIME(column,'format')). Error terjadi jika Anda menggunakan fungsi lain.

      Catatan

      Untuk informasi lebih lanjut tentang cara mendefinisikan kunci partisi, lihat partition_options (Kunci partisi dan siklus hidup).

      Bagaimana cara melihat siklus hidup tabel partisi?

      Jalankan pernyataan SHOW CREATE TABLE <nama_tabel> untuk melihat pernyataan CREATE TABLE, yang mencakup siklus hidup tabel partisi.

      Saya mengatur siklus hidup ke 30 hari. Mengapa saya masih dapat mengkueri data yang lebih tua dari 30 hari?

      Masalah ini terjadi karena alasan berikut:

      • Partisi baru saja kedaluwarsa, tetapi sistem belum menghapusnya. Sistem tidak segera menghapus data partisi yang kedaluwarsa; sistem hanya menghapus data tersebut setelah job BUILD tabel selesai.

      • Untuk tabel yang dibuat di kluster yang menjalankan versi kernel sebelum 3.2.1.1, LIFECYCLE menentukan jumlah partisi yang disimpan per shard. Masalah ini dapat terjadi jika jumlah partisi aktual di shard kurang dari nilai LIFECYCLE yang ditentukan. Masalah ini tidak terjadi untuk tabel yang dibuat di kluster yang menjalankan versi kernel 3.2.1.1 atau lebih baru.

        Contoh:

        • Distribusi data tidak merata: Asumsikan data dipartisi berdasarkan tanggal. Shard 1 berisi partisi dari 20231201 hingga 20231230, dan Shard 2 berisi partisi dari 20231202 hingga 20231231. Dalam kasus ini, kedua shard memiliki 30 partisi, yang tidak melebihi nilai LIFECYCLE 30. Oleh karena itu, tidak ada partisi yang dihapus dari kedua shard, dan Anda dapat mengkueri data dari 20231201 hingga 20231231.

        • Tidak ada data baru yang ditulis dalam periode panjang: Asumsikan data dipartisi berdasarkan tanggal, dan Shard 1 berisi partisi 20231201, 20231202, 20231203, dan 20231204. Jika tidak ada data partisi baru yang ditulis ke tabel setelah 20231204, Shard 1 hanya memiliki empat partisi. Jumlah ini tidak melebihi nilai LIFECYCLE 30, sehingga tidak ada partisi yang dihapus. Anda masih dapat mengkueri data dari 20231201 bahkan setelah 20231231.

      Apakah data di partisi yang kedaluwarsa dihapus segera?

      Tidak. Sistem tidak membuat atau menghapus partisi secara real-time. Setelah partisi kedaluwarsa, sistem hanya menghapusnya setelah job BUILD tabel selesai.

      Indeks

      Bagaimana cara mengkueri indeks terkluster tabel?

      Jalankan pernyataan SHOW CREATE TABLE untuk melihat indeks terkluster yang didefinisikan dalam pernyataan CREATE TABLE.

      Apakah AnalyticDB for MySQL mendukung indeks unik?

      AnalyticDB for MySQL tidak mendukung kendala UNIQUE INDEX. Namun, indeks kunci primer di AnalyticDB for MySQL adalah indeks unik dan memastikan bahwa nilai kunci primer unik dalam tabel.

      Apakah indeks gabungan, seperti INDEX(column1, column2), didukung?

      Tidak. AnalyticDB for MySQL tidak mendukung indeks gabungan. Indeks hanya dapat berisi satu kolom, seperti INDEX(column1).

      Penyimpanan berorientasi kolom

      Apa arti TABLE_PROPERTIES='{"format":"columnstore"}' dalam pernyataan CREATE TABLE?

      Klausa TABLE_PROPERTIES='{"format":"columnstore"}' adalah nilai tetap yang menentukan format penyimpanan berorientasi kolom untuk data di ENGINE. Anda tidak perlu menentukan properti ini secara manual saat membuat tabel.

      Apakah tabel mendukung penggunaan penyimpanan berorientasi baris untuk beberapa partisi dan penyimpanan berorientasi kolom untuk partisi lain?

      Tidak.

      Lainnya

      Setelah tabel dibuat, parameter mana yang dapat dimodifikasi menggunakan pernyataan ALTER TABLE?

      Anda dapat menggunakan pernyataan ALTER TABLE untuk memodifikasi parameter berikut:

      • table_name, column_name, column_type, dan COMMENT

      • Menambah dan menghapus kolom, kecuali kolom kunci primer

      • Nilai default kolom

      • Mengubah NOT NULL menjadi NULL

      • Menambah dan menghapus indeks INDEX

      • Format tanggal fungsi partisi

      • Siklus hidup

      • Kebijakan penyimpanan

      Untuk informasi lebih lanjut tentang sintaksis, lihat ALTER TABLE.

      Anda tidak dapat memodifikasi parameter lain setelah tabel dibuat.

      Berapa jumlah maksimum tabel yang dapat dibuat dalam kluster?

      Edisi kluster menentukan jumlah maksimum tabel yang dapat Anda buat di kluster AnalyticDB for MySQL:

      • Edisi Perusahaan: 80000/(Jumlah shard/Jumlah node sumber daya reservasi/3). Nilai Jumlah shard/Jumlah node sumber daya reservasi/3 dibulatkan ke atas. Anda dapat menambahkan node sumber daya reservasi untuk meningkatkan batas jumlah tabel internal.

      • Edisi Dasar: 80000/(Jumlah shard/Jumlah node sumber daya reservasi). Nilai (Jumlah shard/Jumlah node sumber daya reservasi) dibulatkan ke atas. Anda dapat menambahkan node sumber daya reservasi untuk meningkatkan batas jumlah tabel internal.

      • Edisi Perusahaan, Edisi Dasar, Edisi Data Lakehouse, dan kluster Edisi Gudang Data (Mode Elastis) mendukung maksimal 500.000 tabel eksternal.

      • Edisi Data Lakehouse: Batas jumlah tabel internal adalah [80000/(Jumlah shard/Jumlah kelompok sumber daya penyimpanan reservasi)]*2. Satu kelompok sumber daya penyimpanan reservasi adalah 24 ACU. Misalnya, jika kluster memiliki 48 ACU sumber daya penyimpanan reservasi, jumlah kelompoknya adalah 2. Anda dapat meningkatkan sumber daya penyimpanan reservasi untuk meningkatkan batas jumlah tabel internal.

      • Edisi Gudang Data (Mode Elastis): Batas jumlah tabel internal adalah [80000/(Jumlah shard/Jumlah EIUs)]*2. Nilai Jumlah shard/Jumlah EIUs dibulatkan ke atas. EIU adalah singkatan dari elastic I/O unit. Anda dapat menambahkan EIUs untuk meningkatkan batas jumlah tabel internal.

      • Edisi Gudang Data (Mode Reservasi) dengan 1 hingga 20 kelompok node: Batas jumlah tabel internal adalah 80000/(Jumlah shard/Jumlah kelompok node). Nilai Jumlah shard/Jumlah kelompok node dibulatkan ke atas. Anda dapat menambahkan kelompok node untuk meningkatkan batas jumlah tabel internal.

      Catatan

      Untuk mengkueri jumlah shard, jalankan pernyataan SELECT COUNT(1) FROM information_schema.kepler_meta_shards;. Jumlah shard tidak dapat diubah.

      Apa set karakter default AnalyticDB for MySQL?

      Set karakter default untuk AnalyticDB for MySQL adalah utf-8, yang setara dengan set karakter utf8mb4 MySQL. Set karakter lain tidak didukung.

      Bagaimana cara menentukan apakah tabel adalah tabel internal atau eksternal?

      Anda dapat menjalankan pernyataan SHOW CREATE TABLE db_name.table_name; untuk melihat pernyataan DDL tabel. Jika pernyataan DDL tidak mengandung parameter ENGINE, atau jika nilai parameter ENGINE adalah XUANWU atau XUANWU_V2, tabel tersebut adalah tabel internal; jika tidak, tabel tersebut adalah tabel eksternal.

      Error umum

      partition number must larger than 0

      Penyebab: Pernyataan CREATE TABLE mendefinisikan partisi tetapi tidak menentukan siklus hidupnya.

      Pernyataan CREATE TABLE berikut menyebabkan error ini:

      CREATE TABLE test (
        id INT COMMENT '',
        name VARCHAR(10) COMMENT '',
        PRIMARY KEY (id, name)
      ) 
      DISTRIBUTED BY HASH(id) PARTITION BY VALUE(name);

      Solusi: Tentukan siklus hidup partisi dalam pernyataan CREATE TABLE. Misalnya:

      CREATE TABLE test (
        id INT COMMENT '',
        name VARCHAR(10) COMMENT '',
        PRIMARY KEY (id, name)
      ) 
      DISTRIBUTED BY HASH(id) PARTITION BY VALUE(name) LIFECYCLE 30;
      Catatan

      Error ini hanya terjadi pada kluster yang menjalankan versi kernel sebelum 3.2.1.0.

      Only 204800 partition allowed, the number of existing partition=>196462

      Penyebab: Error ini terjadi saat jumlah partisi di kluster AnalyticDB for MySQL melebihi batas 204.800.

      Untuk mengkueri jumlah partisi di kluster, jalankan pernyataan berikut:

      SELECT count(partition_id)
      FROM information_schema.kepler_partitions
      WHERE partition_id > 0;

      Solusi: Gunakan pernyataan ALTER TABLE untuk menyesuaikan granularitas partisi. Misalnya, ubah partisi dari harian ke bulanan.

      partition column 'XXX' is not found in primary index=> [YYY]

      Penyebab: Kunci primer harus mencakup kunci distribusi dan kunci partisi.

      Contoh pernyataan SQL salah 1:

      CREATE TABLE test (
        id INT COMMENT '',
        name VARCHAR(10) COMMENT '',
        PRIMARY KEY (id)
      ) 
      DISTRIBUTED BY HASH(id) PARTITION BY VALUE(name) LIFECYCLE 30;

      Error ini juga terjadi jika Anda menghilangkan kunci primer dan kunci distribusi. Dalam skenario ini, AnalyticDB for MySQL secara otomatis membuat kolom bernama __adb_auto_id__ dan menetapkannya sebagai kunci primer sekaligus kunci distribusi. Operasi gagal karena kunci primer yang dihasilkan, yaitu hanya __adb_auto_id__, tidak mencakup kunci partisi.

      Contoh pernyataan SQL salah 2:

      CREATE TABLE test (
        id INT COMMENT '',
        name VARCHAR(10) COMMENT ''
      ) 
      PARTITION BY VALUE(name) LIFECYCLE 30;

      Solusi: Tambahkan kunci partisi ke definisi PRIMARY KEY.

      SemanticException:only 5000 table allowed

      Penyebab: Error ini terjadi saat jumlah total tabel di kluster AnalyticDB for MySQL, termasuk yang sedang digunakan dan di keranjang daur ulang tabel, melebihi batas. Batas tabel bervariasi berdasarkan seri produk dan spesifikasinya. Untuk informasi lebih lanjut, lihat Batas jumlah tabel.

      Solusi:

      unsigned expr not supported

      Penyebab: AnalyticDB for MySQL tidak mendukung angka tak bertanda, sehingga atribut UNSIGNED tidak diizinkan.

      Solusi: Hapus atribut UNSIGNED dari pernyataan CREATE TABLE Anda. Anda harus menerapkan kendala nilai non-negatif di kode aplikasi Anda.

      Topik terkait