全部产品
Search
文档中心

AnalyticDB:Gunakan pernyataan CREATE TABLE untuk membuat tabel partisi dan tabel replikasi

更新时间:Dec 11, 2025

Topik ini menjelaskan cara membuat tabel partisi dan tabel replikasi menggunakan pernyataan CREATE TABLE di AnalyticDB for MySQL, serta cara menentukan kunci distribusi, kunci partisi, indeks, siklus hidup partisi, dan kebijakan penyimpanan bertingkat untuk data panas dan dingin pada tabel.

Skema distribusi data tabel

Gambar berikut menunjukkan konsep yang perlu Anda pahami sebelum membuat tabel, seperti shard, partisi, dan indeks terkluster.

Sintaks

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

Secara default, tabel internal AnalyticDB for MySQL menggunakan algoritma kompresi zstd.

Parameter

table_name, column_name, column_type, dan COMMENT

Parameter

Deskripsi

table_name

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

Anda dapat menggunakan format db_name.table_name untuk menentukan tabel yang ingin dibuat dalam suatu database.

column_name

Nama kolom yang ingin ditambahkan ke tabel. Nama kolom harus terdiri dari 1 hingga 127 karakter dan dapat berisi huruf, angka, serta garis bawah (_). Nama kolom harus dimulai dengan huruf atau garis bawah (_).

column_type

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

COMMENT

Komentar untuk kolom atau tabel.

column_attributes (DEFAULT | AUTO_INCREMENT)

DEFAULT {constant | CURRENT_TIMESTAMP}

Menentukan nilai default kolom. Nilai default dapat berupa konstanta atau fungsi CURRENT_TIMESTAMP. Fungsi atau ekspresi variabel lain tidak didukung.

Jika tidak ada nilai yang ditentukan, nilai default kolom adalah NULL.

AUTO_INCREMENT

Menentukan kolom auto-increment. Kolom auto-increment harus bertipe BIGINT.

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

Penting
  • Saat memasukkan data ke tabel yang memiliki kolom auto-increment, disarankan agar Anda secara eksplisit menentukan nama kolomnya. Contoh: INSERT INTO table (column1,column2) VALUES (value1,value2). Hal ini mencegah pesan error seperti Insert query has mismatched column sizes yang disebabkan oleh ketidaksesuaian jumlah atau urutan kolom.

  • Karena sifat sistem terdistribusi, saat data ditulis melalui INSERT INTO SELECT selama proses ETL, kolom auto-increment hanya menjamin keunikan dalam satu pekerjaan ETL, bukan antar beberapa pekerjaan ETL.

column_constraints (NOT NULL | PRIMARY KEY)

NOT NULL

Menentukan kolom NOT NULL, yang tidak boleh berisi nilai NULL. Kolom yang ditentukan sebagai NULL atau tidak ditentukan sebagai NOT NULL dapat berisi nilai NULL.

PRIMARY KEY

Menentukan kunci primer. Anda hanya dapat menentukan satu kolom sebagai kunci primer melalui batasan kolom. Misalnya, Anda dapat menentukan kolom id sebagai kunci primer dengan id BIGINT NOT NULL PRIMARY KEY. Untuk menentukan beberapa kolom sebagai kunci primer, gunakan kunci primer gabungan dalam table_constraints.

table_constraints (Indeks)

AnalyticDB for MySQL mendukung berbagai jenis indeks, termasuk INDEX, PRIMARY KEY, CLUSTERED KEY, FOREIGN KEY, FULLTEXT INDEX, dan ANN INDEX. Sebuah tabel dapat memiliki satu atau lebih jenis indeks.

INDEX | KEY

Menentukan indeks biasa. INDEX dan KEY dapat digunakan secara bergantian.

  • Untuk tabel XUANWU_V2, AnalyticDB for MySQL tidak membuat indeks pada semua kolom tabel secara default. Jika kunci primer ditentukan untuk tabel, AnalyticDB for MySQL hanya membuat indeks biasa pada kunci primer secara default.

  • Untuk tabel XUANWU, indeks dibuat pada semua kolom tabel secara default. Namun, jika Anda membuat indeks pada kolom tertentu saat membuat tabel XUANWU, seperti indeks pada kolom id dengan INDEX (id), AnalyticDB for MySQL tidak secara otomatis membuat indeks pada kolom lainnya.

Catatan: Anda tidak dapat menggunakan INDEX (column1,column2) untuk membuat indeks gabungan pada beberapa kolom.

PRIMARY KEY

Menentukan indeks kunci primer.

Ikhtisar

  • 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 gabungan harus mencakup kunci distribusi dan kunci partisi. Disarankan agar Anda menempatkan kunci distribusi dan partisi di bagian awal kunci primer gabungan.

Catatan penggunaan

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

  • Jika tidak ada kunci primer yang ditentukan, aturan berikut berlaku:

    • Jika tidak ada kunci distribusi yang ditentukan, AnalyticDB for MySQL secara otomatis menambahkan kolom __adb_auto_id__ ke tabel dan menggunakan kolom tersebut sebagai kunci primer dan kunci distribusi.

    • Jika kunci distribusi ditentukan, AnalyticDB for MySQL tidak secara otomatis menambahkan kunci primer.

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

Untuk memastikan performa tinggi, disarankan agar Anda memilih satu atau sedikit kolom numerik sebagai kunci primer.

Catatan

Jika sebuah tabel memiliki terlalu banyak kolom kunci primer, masalah berikut dapat terjadi:

  • Konsumsi sumber daya CPU dan I/O yang lebih tinggi. Hal ini karena AnalyticDB for MySQL memeriksa apakah ada nilai kunci primer duplikat saat data ditulis.

  • Penggunaan disk yang lebih tinggi untuk indeks kunci primer. Untuk melihat penggunaan disk indeks kunci primer, gunakan fitur Storage Analysis.

  • Kecepatan pembangunan ulang partisi pekerjaan BUILD yang lebih lambat.

CLUSTERED KEY

Menentukan indeks terkluster. Indeks terkluster dikonfigurasi pada tingkat partisi. Indeks ini menentukan urutan fisik penyimpanan data. Data dalam partisi diurutkan dan disimpan secara berurutan berdasarkan nilai indeks terkluster. Secara default, data diurutkan dan disimpan dalam urutan naik. Catatan data dengan nilai kunci indeks terkluster yang sama atau mirip disimpan dalam blok data yang sama atau berdekatan. Dalam kueri rentang atau penyaringan kesetaraan, penggunaan indeks terkluster dapat mengurangi I/O disk dan mempercepat pembacaan data. Hal ini karena mesin penyimpanan dapat membaca blok data berurutan saat kondisi kueri sesuai dengan kolom indeks terkluster.

Contoh

Skenario yang berlaku

Indeks terkluster bekerja baik dengan kueri rentang dan penyaringan kesetaraan. Kolom yang sering digunakan dalam kondisi kueri rentang atau penyaringan kesetaraan merupakan kolom indeks terkluster yang ideal.

Saat kondisi kueri cocok atau sebagian cocok dengan kolom indeks terkluster, efisiensi pembacaan meningkat secara signifikan. Misalnya, Anda dapat menggunakan ID pengguna sebagai indeks terkluster dalam aplikasi software-as-a-service (SaaS). Hal ini memastikan catatan ID pengguna tertentu disimpan dalam blok data yang sama atau berurutan dan meningkatkan performa kueri data.

Catatan penggunaan

  • Setiap tabel hanya dapat memiliki satu indeks terkluster.

  • Indeks terkluster dapat dibuat pada satu kolom, seperti CLUSTERED KEY index(id), atau pada beberapa kolom, seperti CLUSTERED KEY index(id,name). Saat indeks terkluster melibatkan dua kolom, data pertama kali diurutkan berdasarkan nilai kolom indeks terkluster pertama. Jika nilai kolom indeks terkluster pertama sama, data diurutkan berdasarkan nilai kolom indeks terkluster kedua. Oleh karena itu, CLUSTERED KEY index(id,name) dan CLUSTERED KEY index(name,id) adalah indeks terkluster yang berbeda.

  • Secara default, indeks terkluster diurutkan dalam urutan naik dan cocok untuk kueri naik. Jika kueri Anda dalam urutan turun, atur urutan indeks terkluster menjadi turun saat membuat tabel, seperti CLUSTERED KEY index(id) DESC. Jika Anda ingin mengkueri data dari tabel yang sudah ada, Anda dapat menghapus indeks terkluster yang ada dan membuat indeks terkluster dalam urutan turun.

  • Untuk mencegah penurunan performa pengurutan, disarankan agar Anda tidak menggunakan kolom yang memiliki nilai panjang (seperti string lebih dari 10 KB) dalam indeks terkluster.

FULLTEXT INDEX | FULLTEXT KEY

Menentukan indeks teks penuh.

Sintaks dan parameter

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

Parameter

FOREIGN KEY

Menentukan indeks kunci asing. Indeks kunci asing digunakan untuk menghilangkan join yang tidak perlu.

Sintaks dan parameter

Versi yang didukung

Hanya kluster AnalyticDB for MySQL versi V3.1.10 atau lebih baru yang mendukung klausa FOREIGN KEY.

Catatan

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

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

Parameter

  • symbol: nama kendala kunci asing. Nama harus unik dalam satu tabel. Parameter ini opsional. Jika tidak ditentukan, parser secara otomatis menggunakan nama kolom kunci asing dengan akhiran _fk sebagai nama kendala kunci asing.

  • fk_column_name: nama kolom kunci asing. Kolom harus sudah ada.

  • pk_table_name: nama tabel utama. Tabel utama harus sudah ada.

  • pk_column_name: nama kolom kendala kunci asing, yaitu kolom kunci primer tabel utama. Kolom harus sudah ada.

Catatan penggunaan

  • Setiap tabel dapat memiliki beberapa indeks kunci asing.

  • Indeks kunci asing tidak dapat terdiri dari beberapa kolom, seperti FOREIGN KEY (sr_item_sk, sr_ticket_number) REFERENCES store_sales(ss_item_sk,d_date_sk).

  • AnalyticDB for MySQL tidak memeriksa kendala data. Anda harus memeriksa hubungan kendala data antara kunci primer tabel utama dan kunci asing tabel terkait.

  • Anda tidak dapat menambahkan kendala kunci asing ke tabel eksternal.

ANN INDEX

Menentukan indeks vektor.

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

Sintaks dan parameter

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

Parameter

  • index_name: nama indeks vektor.

  • column_name: nama kolom vektor. Kolom vektor harus bertipe salah satu dari berikut: ARRAY<FLOAT>, ARRAY<SMALLINT>, dan ARRAY<BYTE>. Anda harus menentukan dimensi vektor. Misalnya, Anda dapat menggunakan sintaks berikut untuk membuat kolom vektor empat dimensi bertipe ARRAY<FLOAT> bernama feature: feature array<float>(4).

  • index_option: atribut indeks vektor.

    • algorithm: algoritma yang digunakan dalam rumus perhitungan jarak antar vektor. Atur nilainya ke HNSW_PQ, yang cocok untuk dataset berukuran sedang yang sensitif terhadap dimensi vektor dan melibatkan 1 juta hingga 10 juta catatan per tabel.

    • dis_function: rumus yang digunakan untuk menghitung jarak antar vektor. Atur nilainya ke SquaredL2. Rumus perhitungan: (x1 - y1)^2 + (x2 - y2)^2 + ....

JSON INDEX

Menentukan indeks JSON atau indeks array JSON.

Sintaks dan parameter

Indeks JSON

Versi yang didukung

  • Untuk kluster AnalyticDB for MySQL versi V3.1.5.10 atau lebih baru, tidak ada indeks JSON yang dibuat secara otomatis setelah Anda membuat tabel. Anda harus membuat indeks JSON secara manual.

  • Untuk kluster AnalyticDB for MySQL versi sebelum V3.1.5.10, indeks JSON dibuat secara otomatis untuk kolom JSON setelah Anda membuat tabel.

Catatan

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

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

Parameter

  • index_name: nama indeks.

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

    • column_name: nama kolom tempat Anda ingin membuat indeks JSON.

    • column_name->'$.json_path': kolom JSON dan kunci propertinya. Setiap indeks JSON hanya melibatkan satu kunci properti dari kolom JSON.

      Penting
      • Hanya kluster AnalyticDB for MySQL versi V3.1.6.8 atau lebih baru yang mendukung parameter column_name->'$.json_path.

      • Jika kolom JSON sudah memiliki indeks, Anda harus menghapus indeks untuk kolom JSON tersebut sebelum dapat membuat indeks untuk kunci properti kolom JSON.

Indeks array JSON

Versi yang didukung

Hanya kluster AnalyticDB for MySQL versi V3.1.10.6 atau lebih baru yang mendukung indeks array JSON.

Catatan

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

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

Parameter

  • index_name: nama indeks.

  • column_name->'$[*]': nama kolom tempat Anda ingin membuat indeks array JSON. Misalnya, vj->'$[*]' digunakan untuk membuat indeks array JSON pada kolom vj.

table_attribute (Kunci distribusi)

Menentukan apakah tabel merupakan tabel standar atau tabel replikasi.

  • DISTRIBUTED BY HASH: menentukan tabel sebagai tabel standar. Tabel standar dapat memanfaatkan sepenuhnya kemampuan kueri sistem terdistribusi untuk meningkatkan efisiensi kueri. Setiap tabel standar dapat menyimpan hingga ratusan miliar catatan data.

  • DISTRIBUTED BY BROADCAST: menentukan tabel sebagai tabel replikasi. Tabel replikasi menyimpan salinan data di setiap shard kluster AnalyticDB for MySQL tempat tabel tersebut berada. Disarankan agar Anda menyimpan maksimal 20.000 baris di setiap tabel replikasi.

DISTRIBUTED BY HASH (column_name,...)

Menentukan kunci distribusi tabel. Tabel yang memiliki kunci distribusi adalah tabel partisi (tabel standar). AnalyticDB for MySQL menghitung nilai hash kunci distribusi dan membagi tabel menjadi shard berdasarkan nilai hash tersebut. Sharding meningkatkan skalabilitas dan performa kueri.

Contoh

Ikhtisar

  • Setiap tabel hanya dapat memiliki satu kunci distribusi.

  • Setiap kunci distribusi dapat berisi satu atau beberapa kolom.

  • Kolom kunci distribusi harus termasuk dalam kolom kunci primer. Misalnya, jika kunci distribusi adalah kolom customer_id, kunci primer harus mencakup kolom customer_id.

Catatan penggunaan

  • Jika Anda tidak menentukan kunci distribusi saat membuat tabel, aturan berikut berlaku:

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

    • Jika tabel tidak memiliki kunci primer, AnalyticDB for MySQL secara otomatis menambahkan kolom __adb_auto_id__ ke tabel dan menggunakan kolom tersebut sebagai kunci primer dan kunci distribusi.

  • Setelah tabel dibuat, Anda tidak dapat menambah, menghapus, atau mengubah kolom kunci distribusi. Untuk mengubah kunci distribusi, Anda harus membuat tabel dengan kunci distribusi yang diinginkan dan memigrasikan data ke tabel baru tersebut.

Rekomendasi

  • Pilih lebih sedikit kolom agar kunci distribusi lebih cocok untuk berbagai kueri kompleks.

  • Pilih kolom yang nilainya terdistribusi merata sebagai kunci distribusi, seperti ID transaksi, ID perangkat, ID pengguna, atau kolom auto-increment. Namun, kolom-kolom ini bukan kunci distribusi yang ideal ketika kondisi kueri dibatasi pada sejumlah kecil nilai kolom. Misalnya, jika Kolom A memiliki nilai yang terdistribusi merata tetapi kondisi kueri selalu A=3, menetapkan Kolom A sebagai kunci distribusi menyebabkan hotspot data.

  • Pilih kolom yang dapat digunakan untuk menggabungkan tabel sebagai kunci distribusi. Dengan cara ini, data dengan nilai kunci distribusi yang sama di dua tabel yang digabungkan didistribusikan ke shard yang sama. Operasi join dilakukan pada shard yang sama tanpa perlu transmisi data antar shard. Hal ini meminimalkan redistribusi data dan meningkatkan performa kueri. Misalnya, jika skenario penggunaan Anda melibatkan kueri riwayat pesanan pelanggan, Anda dapat menentukan kolom customer_id sebagai kunci distribusi.

  • Jangan pilih kolom bertipe tanggal, waktu, dan stempel waktu sebagai kunci distribusi. Kolom-kolom tersebut rentan terhadap kesenjangan data saat penulisan data dan dapat menurunkan performa penulisan. Sebagian besar kueri dibatasi pada periode waktu tertentu seperti satu hari atau satu bulan. Dalam kasus ini, data yang ingin Anda kueri mungkin hanya ada di satu node, dan kueri tidak dapat memanfaatkan kemampuan pemrosesan semua node dalam sistem database terdistribusi. Disarankan agar Anda memilih kolom bertipe tanggal dan waktu sebagai kunci partisi.

  • Anda dapat menggunakan fitur diagnostik penyimpanan untuk memeriksa apakah suatu kolom cocok sebagai kunci distribusi dan apakah terjadi kesenjangan data.

DISTRIBUTED BY BROADCAST

Menentukan tabel replikasi. Tabel replikasi menyimpan salinan data di setiap shard kluster AnalyticDB for MySQL tempat tabel tersebut berada. Disarankan agar Anda tidak menyimpan data dalam jumlah besar di setiap tabel replikasi.

Keuntungan: Saat melakukan kueri JOIN, Anda tidak perlu mentransmisikan data tabel replikasi ke node yang berbeda. Hal ini secara signifikan mengurangi overhead transmisi jaringan dan meningkatkan stabilitas kluster dalam skenario konkurensi tinggi.

Kerugian: Saat data diubah setelah melakukan operasi INSERT, UPDATE, dan DELETE pada tabel replikasi, perubahan tersebut disiarkan ke semua node kluster untuk memastikan konsistensi data. Namun, hal ini memengaruhi performa penulisan secara keseluruhan. Oleh karena itu, disarankan agar Anda tidak sering membuat, menghapus, atau memodifikasi tabel replikasi.

partition_options (Kunci partisi dan siklus hidup)

Jika satu shard berisi data dalam jumlah besar setelah Anda menentukan kunci distribusi untuk tabel, Anda dapat membagi shard menjadi partisi untuk mempercepat penyaringan data dan meningkatkan performa kueri.

Manfaat

  • Partisi mempercepat penyaringan data dan meningkatkan performa kueri karena alasan berikut:

    • Meningkatkan kecepatan kueri dengan menggunakan fitur pemangkasan partisi. Fitur pemangkasan partisi memungkinkan sistem hanya memindai partisi yang berisi data relevan untuk kueri. Hal ini meningkatkan kecepatan kueri.

    • Meningkatkan performa pemindaian indeks. Jika tabel yang melibatkan jumlah baris berlebihan, seperti 50 juta, tidak dipartisi, efisiensi pemindaian indeks rendah. Jika tabel dipartisi, indeks dibuat untuk setiap partisi. Hal ini menghasilkan pemindaian indeks yang lebih efisien.

    • Meningkatkan efisiensi pekerjaan BUILD. Anda dapat menggunakan pekerjaan BUILD untuk mengonversi data yang ditulis secara real time menjadi data historis. Selama proses tersebut, sistem membuat partisi dan indeks, serta membersihkan data berlebih. Indeks hanya berlaku setelah pekerjaan BUILD selesai. Jika tabel tidak dipartisi, seluruh tabel dipindai untuk setiap pekerjaan BUILD. Semakin banyak catatan yang dimiliki tabel, semakin lama prosesnya dan semakin lambat indeks baru berlaku. Hal ini memengaruhi performa kueri. Jika tabel dipartisi, hanya partisi yang mengalami perubahan data yang dipindai untuk setiap pekerjaan BUILD. Hal ini meningkatkan efisiensi pekerjaan BUILD.

  • Partisi memfasilitasi manajemen siklus hidup data.

  • Partisi membantu Anda menerapkan penyimpanan bertingkat data panas dan dingin berdasarkan kebijakan penyimpanan yang berbeda.

Contoh

PARTITION BY

Menentukan kunci partisi.

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

Parameter

  • column_name: nama kunci partisi. Dalam sintaks PARTITION BY VALUE(column_name), partisi didasarkan pada nilai kolom column_name. Kunci partisi dapat bertipe: numerik, datetime, atau string yang menentukan angka.

  • DATE_FORMAT(column_name, 'format'))|FROM_UNIXTIME(column_name, 'format'): mengonversi kolom datetime ke format tanggal tertentu menggunakan fungsi DATE_FORMAT() atau FROM_UNIXTIME() dan mempartisi data. Format tanggal yang ditentukan hanya mendukung tahun, bulan, dan hari dalam bentuk berikut: %Y, %y, %Y%m, %y%m, %Y%m%d, dan %y%m%d. Setelah tabel dibuat, Anda dapat mengubah format dengan mengeksekusi pernyataan ALTER TABLE.

    • Jika kolom bertipe BIGINT, TIMESTAMP, DATETIME, atau VARCHAR, Anda harus menggunakan fungsi DATE_FORMAT(). Contoh untuk kolom BIGINT: 1734278400000 (stempel waktu UNIX dalam milidetik). Contoh untuk kolom TIMESTAMP, DATETIME, atau VARCHAR: 2024-11-26 00:01:02.

    • Jika kolom bertipe INT, Anda harus menggunakan fungsi FROM_UNIXTIME(). Contoh: 1696266000 (stempel waktu UNIX dalam detik).

Catatan penggunaan

  • Untuk kluster AnalyticDB for MySQL versi sebelum V3.2.1.0, Anda harus menggunakan parameter LIFECYCLE n untuk menentukan siklus hidup partisi saat menggunakan klausa PARTITION BY untuk menentukan kunci partisi. Jika tidak, terjadi error.

  • Untuk kluster AnalyticDB for MySQL versi V3.2.1.0 atau lebih baru, parameter LIFECYCLE n bersifat opsional saat menggunakan klausa PARTITION BY untuk menentukan kunci partisi. Jika Anda tidak menentukan parameter LIFECYCLE n, data partisi tidak dihapus.

  • Setelah tabel dibuat, Anda tidak dapat menambah kunci partisi, atau menambah, menghapus, atau mengubah kolom kunci partisi. Untuk menambah atau mengubah kunci partisi, buat tabel dengan kunci partisi yang diinginkan dan migrasikan data ke tabel baru tersebut. Untuk informasi lebih lanjut, lihat ALTER TABLE.

Rekomendasi

  • Disarankan agar Anda menggunakan kolom datetime sebagai kunci partisi.

  • Partisi yang terlalu besar atau terlalu kecil dapat memengaruhi performa baca/tulis atau bahkan stabilitas kluster. Untuk informasi tentang ukuran partisi yang direkomendasikan dan kriteria kewajaran bidang partisi, lihat bagian "Diagnostik tabel partisi" dalam topik Diagnostik penyimpanan.

  • Disarankan agar Anda tidak sering memperbarui data di partisi historis. Jika Anda sering memperbarui data di partisi historis, Anda mungkin perlu mengubah kunci partisi.

LIFECYCLE n

Parameter LIFECYCLE n harus digunakan bersama dengan klausa PARTITION BY. Anda dapat menggunakan parameter ini untuk mengelola siklus hidup partisi. AnalyticDB for MySQL mengurutkan partisi dalam urutan menurun berdasarkan nilai kunci partisi. n partisi pertama dipertahankan dan partisi lainnya dihapus.

  • Untuk kluster AnalyticDB for MySQL versi sebelum V3.2.1.1, parameter LIFECYCLE n menentukan bahwa maksimal n partisi dapat dipertahankan di setiap shard. Siklus hidup partisi dikelola pada tingkat shard. Namun, jika data tidak terdistribusi merata atau jumlah datanya terlalu kecil, lebih dari n partisi mungkin dipertahankan di shard tertentu.

  • Untuk kluster AnalyticDB for MySQL versi V3.2.1.1 atau lebih baru, siklus hidup partisi dikelola pada tingkat tabel. Parameter LIFECYCLE n menentukan bahwa maksimal n partisi dapat dipertahankan di setiap tabel. Namun, untuk tabel yang dibuat sebelum kluster AnalyticDB for MySQL diperbarui ke V3.2.1.1 atau lebih baru, siklus hidup partisi dikelola pada tingkat shard. Parameter LIFECYCLE n menentukan bahwa maksimal n partisi dapat dipertahankan di setiap shard.

Contoh

PARTITION BY VALUE (DATE_FORMAT(date, '%Y%m%d')) LIFECYCLE 30 menentukan bahwa selama partisi, data di kolom date dikonversi ke format yyyyMMdd dan maksimal 30 partisi dipertahankan. Misalkan data dari tanggal 1 hingga 30 ditulis ke partisi yang sesuai dari Partisi 20231201 hingga Partisi 20231230. Pada tanggal 31 saat data ditulis ke Partisi 20231231, partisi dengan nilai kunci partisi terkecil (Partisi 20231201) secara otomatis dihapus karena hanya maksimal 30 partisi yang dapat dipertahankan.

INDEX_ALL (Indeks pada semua kolom)

Menentukan apakah akan membuat indeks pada semua kolom tabel.

Nilai yang valid:

  • Y: membuat indeks pada semua kolom. Untuk tabel XUANWU, nilai default adalah Y.

  • N: hanya membuat indeks pada kunci primer. Untuk tabel XUANWU_V2, nilai default adalah N.

STORAGE_POLICY (Kebijakan penyimpanan)

Kluster Edisi Perusahaan, Edisi Dasar, dan Edisi Data Lakehouse serta kluster Edisi Gudang Data dalam mode elastis untuk Edisi Kluster memungkinkan Anda menentukan kebijakan penyimpanan data. Kebijakan penyimpanan berbeda dalam performa baca/tulis dan biaya penyimpanan.

Nilai yang valid:

  • hot (default): penyimpanan panas. Data di semua partisi seluruh tabel disimpan di SSD. Penyimpanan panas memiliki performa baca/tulis terbaik tetapi biaya penyimpanan tertinggi.

  • cold: penyimpanan dingin. Data di semua partisi seluruh tabel disimpan di Object Storage Service (OSS). Dibandingkan dengan penyimpanan panas, penyimpanan dingin memiliki performa baca/tulis lebih rendah tetapi merupakan opsi termurah.

  • mixed: kombinasi penyimpanan panas dan dingin, juga disebut penyimpanan bertingkat. Kebijakan ini mengurangi biaya penyimpanan dan memastikan performa kueri dengan menyimpan data yang sering diakses (data panas) di SSD dan data yang jarang diakses (data dingin) di OSS. Jika Anda mengatur parameter STORAGE_POLICY ke mixed, Anda harus menggunakan klausa PARTITION BY untuk menentukan kunci partisi dan parameter hot_partition_count untuk menentukan jumlah partisi panas. Jika Anda tidak menentukan kunci partisi, penyimpanan bertingkat tidak berlaku dan data disimpan di SSD.

    Contoh untuk penyimpanan bertingkat

hot_partition_count (Partisi panas)

Jika Anda mengatur parameter STORAGE_POLICY ke mixed, Anda harus menggunakan hot_partition_count=n (di mana n adalah bilangan bulat positif) untuk menentukan jumlah partisi panas. AnalyticDB for MySQL mengurutkan catatan dalam urutan menurun berdasarkan nilai kunci partisi. n partisi pertama adalah partisi panas dan partisi lainnya adalah partisi dingin.

Catatan

Jika Anda mengatur parameter STORAGE_POLICY ke nilai selain mixed dan menggunakan hot_partition_count=n, terjadi error.

block_size (Blok data)

Blok data adalah unit I/O terkecil untuk membaca dan menulis data. Parameter BLOCK_SIZE menentukan jumlah baris yang disimpan di setiap blok data dalam penyimpanan berorientasi kolom. Parameter ini menentukan jumlah baris yang dibaca dalam setiap operasi I/O dan memengaruhi performa kueri berdasarkan karakteristik kueri. Misalnya, jika BLOCK_SIZE diatur ke nilai besar untuk kueri titik, blok dibaca secara tidak efisien oleh sistem penyimpanan. Dalam kasus ini, Anda dapat mengurangi nilai BLOCK_SIZE secara tepat.

Nilai default:

  • Nilai default untuk tabel replikasi: 4.096.

  • Nilai default untuk kluster AnalyticDB for MySQL Edisi Gudang Data dalam mode elastis untuk Edisi Standalone yang memiliki kurang dari 32 core: 8.192.

  • Nilai default dalam kasus lain: 32.760. Jika nilai default BLOCK_SIZE adalah 32.760, BLOCK_SIZE tidak ditampilkan saat Anda mengeksekusi pernyataan SHOW CREATE TABLE.

Penting

Jika Anda tidak familiar dengan penyimpanan berorientasi kolom, disarankan agar Anda tidak mengubah nilai BLOCK_SIZE.

ENGINE (Mesin penyimpanan)

Menentukan tipe mesin penyimpanan tabel internal AnalyticDB for MySQL. Anda dapat menggunakan mesin penyimpanan ini untuk analisis data historis.

  • Untuk kluster AnalyticDB for MySQL versi sebelum V3.2.2.0, atur nilainya ke XUANWU. Jika Anda tidak secara eksplisit menentukan parameter ENGINE, XUANWU digunakan.

    Penting

    Untuk versi sebelum V3.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, tabel gagal dibuat.

  • Nilai yang valid untuk kluster AnalyticDB for MySQL versi V3.2.2.0 atau lebih baru:

    • Saat RC_DDL_ENGINE_REWRITE_XUANWUV2 diatur ke true: XUANWU_V2.

    • Saat RC_DDL_ENGINE_REWRITE_XUANWUV2 diatur ke false: XUANWU_V2 dan XUANWU.

    Anda dapat mengeksekusi pernyataan SHOW ADB_CONFIG KEY=RC_DDL_ENGINE_REWRITE_XUANWUV2; untuk mengkueri nilai parameter ini. Anda juga dapat memodifikasi nilai RC_DDL_ENGINE_REWRITE_XUANWUV2 pada tingkat kluster atau tabel.

AS query_expr (CTAS)

CREATE TABLE AS query_expr dapat digunakan untuk membuat tabel dan menulis data yang dikueri ke tabel baru. Untuk informasi lebih lanjut, lihat CREATE TABLE AS SELECT (CTAS).

Contoh

Buat tabel partisi yang dipartisi otomatis berdasarkan tanggal

Buat tabel partisi bernama sales yang dipartisi otomatis berdasarkan nilai tanggal dari volume sale_time.

CREATE TABLE sales (
  sale_id BIGINT NOT NULL COMMENT 'Order ID',
  customer_id VARCHAR NOT NULL COMMENT 'Customer ID',
  phone_num BIGINT NOT NULL COMMENT 'Phone number',
  revenue DECIMAL(15, 2) COMMENT 'Total amount',
  sale_time TIMESTAMP NOT NULL COMMENT 'Order time',
  PRIMARY KEY (sale_time,sale_id)
 )
DISTRIBUTED BY HASH(sale_id)
PARTITION BY VALUE(DATE_FORMAT(sale_time, '%Y%m%d'));                   

Buat tabel partisi yang dikonfigurasi dengan siklus hidup partisi

Buat tabel partisi bernama customer. Tentukan login_time, customer_id, dan phone_num sebagai kunci primer gabungan, customer_id sebagai kunci distribusi, dan login_time sebagai kunci partisi. Atur siklus hidup partisi ke 30.

Semua partisi diurutkan dalam urutan menurun berdasarkan nilai kunci partisi login_time. Hanya 30 partisi pertama yang dipertahankan. Saat data ditulis ke partisi ke-31, partisi dengan nilai kunci partisi terkecil secara otomatis dihapus.

Misalkan data dari tanggal 1 (dengan nilai login_time 20231201) hingga tanggal 30 (dengan nilai login_time 20231230) ditulis ke partisi yang sesuai dari Partisi 20231201 hingga Partisi 20231230. Saat data dengan nilai login_time 20231231 ditulis ke database pada tanggal 31, partisi dengan nilai login_time terkecil (Partisi 20231201) secara otomatis dihapus. Dengan cara ini, hanya data dalam 30 hari terakhir yang dipertahankan.

CREATE TABLE customer (
  customer_id BIGINT NOT NULL COMMENT 'Customer ID',
  customer_name VARCHAR NOT NULL COMMENT 'Customer name',
  phone_num BIGINT NOT NULL COMMENT 'Phone number',
  city_name VARCHAR NOT NULL COMMENT 'City',
  sex INT NOT NULL COMMENT 'Gender',
  id_number VARCHAR NOT NULL COMMENT 'ID card number',
  home_address VARCHAR NOT NULL COMMENT 'Home address',
  office_address VARCHAR NOT NULL COMMENT 'Office address',
  age INT NOT NULL COMMENT 'Age',
  login_time TIMESTAMP NOT NULL COMMENT 'Logon time',
  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 'Customer information table';                   

Buat tabel non-partisi

Buat tabel non-partisi tanpa kunci distribusi atau partisi

Jika Anda membuat tabel yang memiliki kunci primer tetapi tidak memiliki kunci distribusi, AnalyticDB for MySQL secara otomatis menggunakan kunci primer sebagai kunci distribusi.

CREATE TABLE orders (
  order_id BIGINT NOT NULL COMMENT 'Order ID',
  customer_id INT NOT NULL COMMENT 'Customer ID',
  order_status VARCHAR(1) NOT NULL COMMENT 'Order status',
  total_price DECIMAL (15, 2) NOT NULL COMMENT 'Total amount',
  order_date DATE NOT NULL COMMENT 'Order date',
  PRIMARY KEY(order_id,order_date)
);

Kueri pernyataan yang digunakan untuk membuat tabel dan verifikasi bahwa kolom kunci primer order_id dan order_date digunakan sebagai kunci distribusi.

SHOW CREATE TABLE orders;
+---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| Table   | Create Table                                                                                                                                  | 
+---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| orders  | CREATE TABLE `orders` (                                                                                                                       |
|         | 'order_id' bigint NOT NULL COMMENT 'Order ID',                                                                                                   |
|         | 'customer_id' int NOT NULL COMMENT 'Customer ID',                                                                                                   |
|         | 'order_status' varchar(1) NOT NULL COMMENT 'Order status',                                                                                         | 
|         | 'total_price' decimal(15, 2) NOT NULL COMMENT 'Total amount',                                                                                      |
|         | 'order_date' date NOT NULL COMMENT 'Order date',                                                                                                 |
|         | 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)

Buat tabel non-partisi tanpa kunci primer atau distribusi

Jika Anda membuat tabel yang tidak memiliki kunci primer atau kunci distribusi, AnalyticDB for MySQL menambahkan kolom __adb_auto_id__ ke tabel dan menggunakan kolom tersebut sebagai kunci primer dan kunci distribusi.

CREATE TABLE orders_new (
  order_id BIGINT NOT NULL COMMENT 'Order ID',
  customer_id INT NOT NULL COMMENT 'Customer ID',
  order_status VARCHAR(1) NOT NULL COMMENT 'Order status',
  total_price DECIMAL (15, 2) NOT NULL COMMENT 'Total amount',
  order_date DATE NOT NULL COMMENT 'Order date'
);

Kueri pernyataan yang digunakan untuk membuat tabel dan verifikasi bahwa kolom auto-increment bernama __adb_auto_id__ secara otomatis ditambahkan ke tabel dan digunakan sebagai kunci primer dan 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 'Order ID',                                                                                                   |
|             | 'customer_id' int NOT NULL COMMENT 'Customer ID',                                                                                                   |
|             | 'order_status' varchar(1) NOT NULL COMMENT 'Order status',                                                                                         | 
|             | 'total_price' decimal(15, 2) NOT NULL COMMENT 'Total amount',                                                                                      |
|             | 'order_date' date NOT NULL COMMENT 'Order date',                                                                                                 |
|             | 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)

Buat tabel non-partisi dengan kunci primer dan distribusi tetapi tanpa kunci partisi

Buat tabel bernama supplier yang menggunakan kolom auto-increment supplier_id sebagai kunci distribusi dan di-shard berdasarkan nilai hash supplier_id.

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

Tentukan kebijakan penyimpanan

Tentukan kebijakan penyimpanan dingin

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';

Tentukan kebijakan penyimpanan panas

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';

Tentukan kebijakan penyimpanan bertingkat dan atur jumlah partisi panas ke 16

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

Buat 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);

Tentukan 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);

Tentukan 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 tentang cara membuat dan mengubah indeks teks penuh, lihat Buat indeks teks penuh.

Untuk informasi tentang pencarian teks penuh, lihat Pencarian teks penuh.

Tentukan indeks vektor

Buat tabel yang memiliki kolom vektor empat dimensi bertipe ARRAY<SMALLINT> bernama short_feature dan kolom vektor empat dimensi bertipe ARRAY<FLOAT> bernama float_feature.

Buat indeks vektor bernama short_feature_index dan float_feature_index pada kolom vektor untuk tabel tersebut.

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 informasi lebih lanjut tentang pengindeksan vektor dan pencarian vektor, lihat Pencarian vektor.

Tentukan indeks kunci asing

Buat tabel bernama store_returns. Gunakan klausa FOREIGN KEY untuk mengaitkan kolom sr_item_sk tabel store_returns dengan kolom kunci primer customer_id 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)
);

Tentukan indeks array JSON

Buat tabel dan 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 informasi tentang cara membuat dan mengubah indeks array JSON, lihat bagian "Buat indeks array JSON" dalam topik Indeks JSON dan bagian "Indeks array JSON" dalam topik ALTER TABLE.

FAQ

Atribut dan kendala kolom

Apakah kolom auto-increment selalu dimulai dari 1? Apakah semua nilainya unik?

Nilai kolom auto-increment mungkin tidak berurutan dan tidak selalu dimulai dari 1. Namun, semua nilai kolom auto-increment bersifat unik.

Kunci distribusi, kunci partisi, dan siklus hidup

Apa perbedaan antara kunci distribusi dan kunci partisi?

Kunci distribusi digunakan dalam sharding. Berdasarkan nilai hash kunci distribusi, data dalam tabel didistribusikan ke shard yang berbeda. Kunci partisi digunakan dalam partisi. Dalam satu shard, data selanjutnya didistribusikan ke partisi yang berbeda berdasarkan nilai kunci partisi. Gambar berikut menunjukkan cara kerja sharding dan partisi.

Apakah saya harus menentukan kunci distribusi saat membuat tabel?

  • Saat membuat tabel partisi, Anda tidak harus menentukan kunci distribusi. Jika Anda menentukan kunci primer tetapi tidak menentukan kunci distribusi, AnalyticDB for MySQL secara otomatis menggunakan kunci primer sebagai kunci distribusi. Jika Anda tidak menentukan kunci primer atau kunci distribusi, AnalyticDB for MySQL secara otomatis menambahkan kolom __adb_auto_id__ ke tabel dan menggunakan kolom tersebut sebagai kunci distribusi dan kunci primer.

  • Saat membuat tabel replikasi, Anda tidak perlu menentukan kunci distribusi. Namun, Anda harus menggunakan klausa DISTRIBUTED BY BROADCAST untuk menentukan bahwa setiap node penyimpanan kluster AnalyticDB for MySQL menyimpan salinan lengkap data.

Apakah jumlah shard terpengaruh jika saya mengubah spesifikasi kluster?

Tidak, jumlah shard tidak terpengaruh oleh perubahan spesifikasi kluster.

Bagaimana cara mengkueri informasi partisi tabel?

Anda dapat mengeksekusi pernyataan berikut untuk mengkueri informasi partisi tabel:

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

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

Anda tidak dapat melihat informasi partisi setelah membuat tabel partisi karena alasan berikut:

  • Tidak ada data yang ditulis ke tabel. Saat Anda membuat tabel, Anda hanya mengonfigurasi aturan partisi dengan menentukan kunci partisi. Partisi dilakukan berdasarkan nilai kunci partisi. Jika tidak ada data yang ditulis ke tabel, nilai kunci partisi kosong dan tidak ada partisi yang dibuat.

  • Tidak ada pekerjaan BUILD untuk partisi yang selesai. Partisi tidak dibuat secara real time. Anda hanya dapat melihat informasi partisi setelah pekerjaan BUILD tabel selesai.

Solusi:

Tulis data ke tabel dan tunggu pekerjaan BUILD selesai. Kemudian, Anda dapat melihat informasi partisi.

Bagaimana cara mengkueri data dalam partisi tertentu?

Anda dapat menggunakan klausa WHERE <partition_key_name> = '<partition_key_value>' untuk mengkueri data dalam partisi tertentu. Sintaks berikut tidak didukung: SELECT * FROM table PARTITION(202304).

Contoh:

Buat tabel bernama orders_demo yang dipartisi berdasarkan kolom order_date.

CREATE TABLE orders_demo (
  order_id BIGINT NOT NULL COMMENT 'Order ID',
  customer_id INT NOT NULL COMMENT 'Customer ID',
  order_status VARCHAR(1) NOT NULL COMMENT 'Order status',
  total_price DECIMAL (15, 2) NOT NULL COMMENT 'Total amount',
  order_date DATE NOT NULL COMMENT 'Order date',
  PRIMARY KEY(order_id,order_date)
)
DISTRIBUTED BY HASH(order_id) 
PARTITION BY VALUE(date_format(order_date, '%Y%m')) LIFECYCLE 30 ;

Masukkan 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');

Eksekusi pernyataan BUILD untuk membangun tabel partisi.

BUILD TABLE orders_demo;
Jika tabel memenuhi kondisi tertentu, pekerjaan BUILD dipicu secara otomatis pada tabel tersebut. Dalam contoh ini, bangun tabel secara manual untuk memfasilitasi langkah selanjutnya.

Kueri status pekerjaan BUILD. Jika pekerjaan BUILD untuk tabel orders_demo selesai, nilai FINISH dikembalikan untuk field status.

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 2023-10-01, eksekusi pernyataan berikut:

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

Jika kunci partisi bertipe DATETIME, atur klausa WHERE ke WHERE order_date >= "2023-10-01 00:00:00" and order_date < "2023-10-02 00:00:00". Pernyataan contoh:

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

Apakah saya harus menentukan kunci partisi sebagai kondisi filter saat mengkueri data dari tabel partisi?

Jika tabel memiliki kunci partisi, Anda tidak harus menentukan kunci partisi sebagai kondisi filter. Namun, Anda dapat meningkatkan performa kueri dengan menentukan kunci partisi sebagai kondisi filter karena hanya partisi tertentu yang dipindai.

Tipe data apa saja yang didukung untuk kunci partisi?

Kunci partisi dapat bertipe data berikut: numerik, datetime, atau string yang menentukan angka. Tipe data lain dapat menyebabkan error penulisan data.

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

Dapatkah saya menggunakan fungsi selain DATE_FORMAT() dan FROM_UNIXTIME() untuk menentukan kunci partisi?

Tidak, Anda tidak dapat menentukan kunci partisi dengan menggunakan fungsi lain. Anda hanya dapat menentukan kunci partisi dengan menggunakan salah satu fungsi berikut: PARTITION BY VALUE(column_name), PARTITION BY VALUE(date_format(column_name, 'format')), dan PARTITION BY VALUE(FROM_UNIXTIME(column,'format')). Jika Anda menggunakan fungsi lain, terjadi error.

Catatan

Untuk informasi tentang kunci partisi, lihat bagian "partition_options (Kunci partisi dan siklus hidup)" dalam topik ini.

Bagaimana cara mengkueri siklus hidup partisi?

Anda dapat mengeksekusi pernyataan SHOW CREATE TABLE <table_name> untuk melihat siklus hidup partisi. Siklus hidup partisi ditampilkan dalam hasil yang dikembalikan.

Mengapa saya masih dapat mengkueri data yang disimpan lebih dari 30 hari setelah mengonfigurasi data agar hanya dipertahankan selama 30 hari dengan mengatur nilai LIFECYCLE ke 30?

Anda dapat mengkueri data yang disimpan lebih dari 30 hari karena alasan berikut:

  • Partisi tertentu baru saja kedaluwarsa dan belum dihapus. Partisi yang kedaluwarsa tidak dihapus sampai pekerjaan BUILD untuk tabel selesai.

  • Untuk kluster AnalyticDB for MySQL versi sebelum V3.2.1.1 yang menggunakan manajemen siklus hidup partisi tingkat shard, shard dalam tabel berisi partisi lebih sedikit daripada jumlah yang ditentukan oleh parameter LIFECYCLE n. Masalah ini tidak terjadi pada tabel yang dibuat di kluster AnalyticDB for MySQL versi V3.2.1.1 atau lebih baru.

    Akar penyebab:

    • Data tidak ditulis secara konsisten ke shard yang sama. Misalkan data dipartisi berdasarkan tanggal. Shard 1 berisi partisi 20231201 hingga 20231230, dan Shard 2 berisi partisi 20231202 hingga 20231231. Partisi di kedua shard dipertahankan karena kedua shard memiliki 30 partisi, yang tidak melebihi nilai 30 yang ditentukan oleh parameter LIFECYCLE n. Oleh karena itu, Anda dapat mengkueri data di partisi 20231201 hingga 20231231.

    • Tidak ada data baru yang ditulis ke tabel dalam waktu lama. Misalkan data dipartisi berdasarkan tanggal. Shard 1 berisi partisi 20231201, 20231202, 20231203, dan 20231204. Tidak ada data baru yang ditulis ke partisi tersebut. Dalam kasus ini, Shard 1 hanya memiliki empat partisi, yang tidak melebihi nilai 30 yang ditentukan oleh parameter LIFECYCLE n. Oleh karena itu, tidak ada partisi yang dihapus dan Anda masih dapat mengkueri data di Partisi 20231201.

Apakah data di partisi yang kedaluwarsa langsung dihapus?

Tidak, partisi tidak dibuat atau dihapus secara real time. Partisi yang kedaluwarsa tidak dihapus sampai pekerjaan BUILD untuk tabel selesai.

Indeks

Bagaimana cara mengkueri indeks terkluster tabel?

Anda dapat mengeksekusi pernyataan SHOW CREATE TABLE untuk mengkueri indeks terkluster yang ditentukan dalam tabel.

Apakah AnalyticDB for MySQL mendukung indeks unik?

Tidak, AnalyticDB for MySQL tidak mendukung indeks unik. Namun, indeks kunci primer tabel di AnalyticDB for MySQL adalah indeks unik dan memastikan bahwa nilai kunci primer bersifat unik.

Dapatkah saya membuat indeks gabungan pada beberapa kolom dengan INDEX(column1,column2)?

Tidak, Anda tidak dapat membuat indeks gabungan pada beberapa kolom. Indeks biasa hanya dapat berisi satu kolom. Contoh: INDEX(column1).

Penyimpanan berorientasi kolom

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

TABLE_PROPERTIES='{"format":"columnstore"}' menentukan bahwa mesin penyimpanan menggunakan penyimpanan berorientasi kolom. Anda tidak perlu memodifikasi sintaks ini saat membuat tabel.

Dapatkah saya menentukan penyimpanan berorientasi baris untuk partisi tertentu dan penyimpanan berorientasi kolom untuk partisi lain saat membuat tabel?

Tidak, Anda tidak dapat menentukan format penyimpanan yang berbeda untuk partisi dalam satu tabel.

Lainnya

Apa saja yang dapat saya modifikasi dengan menggunakan pernyataan ALTER TABLE setelah membuat tabel?

Anda dapat mengeksekusi pernyataan ALTER TABLE untuk melakukan perubahan berikut:

  • Memodifikasi parameter berikut: table_name, column_name, column_type, dan COMMENT.

  • Menambah dan menghapus kolom kecuali kolom kunci primer.

  • Mengubah nilai default kolom.

  • Mengubah kendala kolom NOT NULL menjadi NULL.

  • Membuat dan menghapus indeks.

  • Mengubah format tanggal fungsi partisi.

  • Mengubah siklus hidup partisi.

  • Mengubah kebijakan penyimpanan.

Perubahan lain tidak dapat dilakukan setelah tabel dibuat. Untuk informasi lebih lanjut, lihat ALTER TABLE.

Berapa banyak tabel yang dapat saya buat untuk setiap kluster?

Batas berikut berlaku untuk jumlah maksimum tabel yang dapat dibuat untuk setiap kluster AnalyticDB for MySQL:

  • Jumlah maksimum tabel internal yang dapat dibuat untuk kluster Edisi Perusahaan: 80.000/(Jumlah shard/Jumlah node resource reservasi/3). Dalam rumus ini, hasil dari Jumlah shard/Jumlah node resource reservasi/3 harus dibulatkan ke atas. Anda dapat menambah node resource reservasi untuk meningkatkan jumlah maksimum tabel internal yang dapat dibuat.

  • Jumlah maksimum tabel internal yang dapat dibuat untuk kluster Edisi Dasar: 80.000/(Jumlah shard/Jumlah node resource reservasi). Dalam rumus ini, hasil dari (Jumlah shard/Jumlah node resource reservasi) harus dibulatkan ke atas. Anda dapat menambah node resource reservasi untuk meningkatkan jumlah maksimum tabel internal yang dapat dibuat.

  • Jumlah maksimum tabel eksternal yang dapat dibuat untuk kluster Edisi Perusahaan, Edisi Dasar, dan Edisi Data Lakehouse atau kluster Edisi Gudang Data dalam mode elastis: 500.000.

  • Jumlah maksimum tabel internal yang dapat dibuat untuk kluster Edisi Data Lakehouse: [80.000/(Jumlah shard/Jumlah resource penyimpanan reservasi dibagi 24 ACUs)] × 2. Anda dapat meningkatkan resource penyimpanan reservasi untuk meningkatkan jumlah maksimum tabel internal yang dapat dibuat.

  • Jumlah maksimum tabel internal yang dapat dibuat untuk kluster Edisi Gudang Data dalam mode elastis: [80.000/(Jumlah shard/Jumlah EIUs)] × 2. Dalam rumus ini, hasil dari [Jumlah shard/Jumlah EIUs] harus dibulatkan ke atas. Anda dapat meningkatkan unit I/O elastis (EIUs) untuk meningkatkan jumlah maksimum tabel internal yang dapat dibuat.

  • Jumlah maksimum tabel internal yang dapat dibuat untuk kluster Edisi Gudang Data dalam mode reservasi yang memiliki 1 hingga 20 grup node: 80.000/(Jumlah shard/Jumlah grup node). Dalam rumus ini, hasil dari [Jumlah shard/Jumlah grup node] harus dibulatkan ke atas. Anda dapat menambah grup node untuk meningkatkan jumlah maksimum tabel internal yang dapat dibuat.

Catatan

Untuk mengkueri jumlah shard, eksekusi pernyataan SELECT COUNT(1) FROM information_schema.kepler_meta_shards;. Anda tidak dapat menambah atau mengurangi jumlah shard.

Apa set karakter bawaan untuk AnalyticDB for MySQL?

AnalyticDB for MySQL menggunakan UTF-8 sebagai set karakter default, yang setara dengan set karakter utf8mb4 untuk MySQL. Set karakter lain tidak didukung.

Bagaimana cara menentukan apakah tabel merupakan tabel internal atau eksternal?

Anda dapat mengeksekusi pernyataan SHOW CREATE TABLE db_name.table_name; untuk mengkueri pernyataan DDL tabel. Jika pernyataan DDL tidak berisi parameter ENGINE, atau nilai parameter ENGINE adalah XUANWU atau XUANWU_V2, tabel tersebut adalah tabel internal. Jika tidak, tabel tersebut adalah tabel eksternal.

Error umum dan troubleshooting

partition number must larger than 0

Penyebab: Anda menentukan kunci partisi tetapi tidak menentukan siklus hidup partisi.

Pernyataan contoh:

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. Pernyataan contoh:

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 AnalyticDB for MySQL versi sebelum V3.2.1.0.

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

Penyebab: Jumlah partisi dalam kluster melebihi batas atas 102.400 di AnalyticDB for MySQL.

Eksekusi pernyataan berikut untuk mengkueri jumlah partisi dalam kluster:

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

Solusi: Eksekusi pernyataan ALTER TABLE untuk meningkatkan granularitas partisi, seperti mengubah granularitas dari hari ke bulan.

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

Penyebab: Kunci primer tabel tidak berisi kunci partisi.

Pernyataan contoh:

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 tidak menentukan kunci primer atau kunci distribusi. Jika Anda tidak menentukan kunci primer atau kunci distribusi saat membuat tabel, AnalyticDB for MySQL secara otomatis menambahkan kolom __adb_auto_id__ ke tabel dan menggunakan kolom tersebut sebagai kunci primer dan kunci distribusi. Dalam kasus ini, kunci primer hanya berisi kolom __adb_auto_id__, tetapi tidak berisi kunci partisi. Oleh karena itu, error ini terjadi.

Pernyataan contoh:

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

Solusi: Sertakan kunci partisi dalam kunci primer.

SemanticException:only 5000 table allowed

Penyebab: Error ini terjadi saat jumlah total tabel dalam kluster AnalyticDB for MySQL melebihi batas atas. Jumlah total tabel mencakup tabel yang sedang digunakan dan tabel yang ada di keranjang daur ulang tabel. Batas atas jumlah tabel bervariasi berdasarkan edisi dan spesifikasi yang berbeda. Untuk informasi lebih lanjut, lihat Batas.

Solusi:

unsigned expr not supported

Penyebab: AnalyticDB for MySQL tidak mendukung atribut UNSIGNED karena tidak mendukung angka tak bertanda.

Solusi: Jangan tentukan atribut UNSIGNED untuk kolom dalam pernyataan CREATE TABLE. Sebagai gantinya, Anda harus menerapkan kendala nilai non-negatif dalam kode bisnis Anda.

Referensi

  • Untuk informasi tentang cara menulis data ke tabel, lihat INSERT INTO.

  • Untuk informasi tentang cara memasukkan hasil kueri ke tabel atau menimpa data tertentu dalam tabel dengan hasil kueri, lihat INSERT SELECT FROM atau INSERT OVERWRITE SELECT.

  • Untuk informasi tentang cara mengimpor data dari sumber data, seperti ApsaraDB RDS, MaxCompute, dan OSS, ke AnalyticDB for MySQL, lihat Impor data.