Rumah  >  Artikel  >  pangkalan data  >  Spesifikasi reka bentuk dan pembangunan MySQ yang paling terperinci [koleksi yang disyorkan]

Spesifikasi reka bentuk dan pembangunan MySQ yang paling terperinci [koleksi yang disyorkan]

藏色散人
藏色散人ke hadapan
2022-01-18 16:16:362155semak imbas

Artikel berikut akan menyusun spesifikasi reka bentuk dan pembangunan MySQL yang paling terperinci untuk anda.

Konvensyen penamaan objek pangkalan data

Objek pangkalan data

Objek pangkalan data ialah komponen pangkalan data termasuk yang berikut: Jadual, Indeks, Paparan, Gambar rajah, Lalai, Peraturan, Pencetus, Prosedur Tersimpan, Tunggu pengguna. Konvensyen penamaan merujuk kepada konvensyen penamaan untuk objek pangkalan data seperti pangkalan data (SKEMA), jadual (JADUAL), indeks (INDEX), kekangan (KEKANGAN), dll. [Cadangan: tutorial video mysql]

Spesifikasi penamaan global untuk objek pangkalan data

1 tengah perkataan Asingkan

2 Nama hanya boleh menggunakan huruf Inggeris, nombor dan garis bawah, bermula dengan huruf Inggeris

3 Elakkan menggunakan perkataan simpanan MySQL seperti: backup, call, group , dsb.

4. Semua objek pangkalan data menggunakan huruf kecil Sebenarnya, adalah mungkin untuk menetapkan sama ada kepekaan huruf besar kecil dalam MySQL Untuk memastikan keseragaman, kami menyeragamkan semua ungkapan huruf kecil di sini.

Konvensyen penamaan pangkalan data

1.

2. Nama pangkalan data secara amnya ialah nama projek, yang mewakili singkatan makna perpustakaan Sebagai contoh, pangkalan data aliran kerja projek IM boleh menjadi im_flow.

3. Set aksara lalai dan klausa peraturan pengumpulan mesti ditambah semasa mencipta pangkalan data. Set aksara lalai ialah UTF8 (dumbo telah dipindahkan untuk menggunakan utf8mb4)

4.

Konvensyen penamaan jadual

1. Nama jadual biasa bermula dengan t_, t mewakili jadual, dan peraturan penamaan ialah modul t (termasuk singkatan makna modul) Jadual (mengandungi singkatan makna jadual), seperti jadual maklumat pendidikan modul pengguna: t_user_eduinfo.

2. Jadual sementara (jadual yang digunakan oleh pelajar RD, QA atau DBA untuk pemprosesan data sementara), peraturan penamaan: akhiran jadual modul awalan temp: temp_user_eduinfo_20210719

3 ( Digunakan untuk menyimpan dan mengarkibkan data sejarah atau sebagai data pemulihan bencana) Peraturan penamaan, akhiran jadual jadual modul awalan bak: bak_user_eduinfo_20210719

4. Jadual dalam modul yang sama menggunakan awalan dan nama jadual yang sama sebanyak mungkin Menyatakan maksud sebanyak mungkin

5. Pelbagai perkataan dipisahkan dengan garis bawah _

6. Nama jadual biasa tidak boleh melebihi 30 aksara Jadual temp dan jadual bak bergantung pada situasi, dan cuba pendekkan, dan nama hendaklah menggunakan huruf kecil

Konvensyen penamaan medan

1 yang mewakili makna sebenar mereka, dengan garis bawah antara perkataan_ Buat sambungan seperti service_ip、service_port.

2. Medan dengan makna yang sama antara jadual mesti mempunyai nama yang sama Contohnya, jadual a dan jadual b kedua-duanya mempunyai masa penciptaan, yang harus disatukan sebagai masa ciptaan akan menyebabkan kekeliruan.

3. Berbilang perkataan dipisahkan dengan garis bawah _

4 Nama medan hendaklah tidak lebih daripada 30 aksara dan penamaan hendaklah dalam huruf kecil

<.>Spesifikasi penamaan indeks

1. Indeks unik dinamakan menggunakan nama medan uni:

. create unique index uni_uid on t_user_basic(uid)

2. Indeks bukan unik dinamakan menggunakan nama medan idx:

. create index idx_uname_mobile on t_user_basic(uname,mobile)

3. Berbilang perkataan dipisahkan dengan garis bawah _.

4. Nama indeks tidak boleh melebihi 50 aksara Nama hendaklah menggunakan huruf kecil.

5. Untuk nama lajur berbilang perkataan, gunakan singkatan yang mewakili sebanyak mungkin makna, seperti indeks gabungan pada

jadual test_contact dan member_id: friend_id. idx_mid_fid

6 Fahami prinsip awalan paling kiri bagi indeks gabungan dan elakkan pembinaan indeks berulang Jika (a,b,c) diwujudkan, ia bersamaan dengan penubuhan (a), (a,b), (a. ,b ,c).

Konvensyen penamaan Lihat

1. Nama paparan bermula dengan v, yang bermaksud struktur lengkap ialah singkatan daripada maksud kandungan pandangan.

2 Jika paparan hanya datang dari satu jadual, ia adalah nama jadual v. Jika paparan dijana oleh perkaitan beberapa jadual, gunakan v dan garis bawah (_) untuk menyambung beberapa nama jadual Nama paparan tidak boleh melebihi 30 aksara. Jika melebihi 30 aksara, gunakan singkatan.

3. Pembangun dilarang sama sekali membuat paparan tanpa keperluan khas.

4. Nama hendaklah huruf kecil.

Konvensyen penamaan prosedur tersimpan

1. Nama prosedur tersimpan bermula dengan sp, yang bermaksud prosedur tersimpan (storage procedure). Pelbagai perkataan disambungkan dengan garis bawah (_). Fungsi prosedur tersimpan harus ditunjukkan dalam penamaannya. Nama prosedur yang disimpan tidak boleh melebihi 30 aksara.

2 Parameter input dalam prosedur tersimpan bermula dengan i_, dan parameter output bermula dengan o_.

3. Nama hendaklah huruf kecil.

create procedure sp_multi_param(in i_id bigint,in i_name varchar(32),out o_memo varchar(100))

Konvensyen penamaan fungsi

1. Nama fungsi bermula dengan func, yang bermaksud fungsi. Selepas itu, berbilang perkataan disambungkan dengan garis bawah (_), dan fungsinya harus ditunjukkan dalam penamaan fungsi. Cuba pastikan nama fungsi tidak melebihi 30 aksara.

2. Nama hendaklah dalam huruf kecil.

create function func_format_date(ctime datetime)

Konvensyen penamaan pencetus

1. Pencetus bermula dengan trig, yang bermaksud pencetus trigger.

2. Bahagian asas menerangkan jadual yang ditambahkan pada pencetus. Nama pencetus tidak boleh melebihi 30 aksara.

3. Akhiran (_i, _u, _d), menunjukkan kaedah pencetus keadaan pencetus (sisipkan, kemas kini atau padam).

4. Nama hendaklah huruf kecil.

DROP TRIGGER IF EXISTS trig_attach_log_d;CREATE TRIGGER trig_attach_log_d AFTER DELETE ON t_dept FOR EACH ROW;

Konvensyen penamaan kekangan

1. uk ialah singkatan kepada UNIQUE KEY. Sebagai contoh, tambahkan kekangan unik pada nama jabatan sesuatu jabatan untuk memastikan tiada nama pendua, seperti berikut:

ALTER TABLE t_dept ADD CONSTRAINT un_name UNIQUE(name);

2. Kekangan kunci asing: nama fk_table, diikuti dengan nama jadual di mana kunci asing terletak dan Nama jadual utama yang sepadan (tidak termasuk t_). Nama jadual anak dan nama jadual induk dipisahkan dengan garis bawah (_). Seperti berikut:

ALTER TABLE t_user ADD CONSTRAINT fk_user_dept FOREIGN KEY(depno) REFERENCES t_dept (id);

3. Kekangan bukan nol: Jika tiada keperluan khas, disarankan agar semua medan menjadi bukan nol secara lalai dan jenis data yang berbeza mesti diberikan nilai lalai.

1 `id` int(11) NOT NULL,2 `name` varchar(30) DEFAULT '',3 `deptId` int(11) DEFAULT ,4 `salary` float DEFAULT NULL,

4. Atas sebab prestasi, adalah disyorkan untuk tidak menggunakan kunci asing melainkan terdapat keperluan khas. Integriti rujukan dikawal oleh kod. Ini juga merupakan amalan biasa kami untuk mengawal integriti dari perspektif program, tetapi jika anda tidak berhati-hati, data kotor juga akan dijana.

5. Nama hendaklah huruf kecil.

Konvensyen penamaan pengguna

1 Format penamaan pengguna yang digunakan dalam pengeluaran ialah code_application

2 Konvensyen penamaan pengguna baca sahaja ialah read_application

Spesifikasi reka bentuk objek pangkalan data

Pemilihan enjin storan

1 mesti digunakan.

Anda boleh melihat enjin lalai semasa melalui show variables likedefault_storage_engine‘. Terdapat terutamanya MyISAM dan InnoDB Bermula dari versi 5.5, enjin InnoDB digunakan secara lalai. Klik di sini untuk berlatih kuiz. Perbezaan asas

ialah: jenis MyISAM tidak menyokong pemprosesan lanjutan seperti pemprosesan transaksi, manakala jenis InnoDB menyokongnya. Jadual jenis MyISAM menekankan prestasi, dan kelajuan pelaksanaannya lebih pantas daripada jenis InnoDB, tetapi tidak menyediakan sokongan transaksi, manakala InnoDB menyediakan sokongan transaksi dan fungsi pangkalan data lanjutan seperti kunci asing.

Pilihan set watak

1. Jika tiada keperluan khas, utf8 atau utf8mb4 mesti digunakan.

Di China, ini adalah cara terbaik untuk memilih format utf8 yang mempunyai sokongan sempurna untuk bahasa Cina dan pelbagai bahasa MySQL yang ditambahkan utf8mb4 pengekodan selepas 5.5, dan mb4 secara khusus direka bentuk agar serasi dengan empat bait most bytes 4. unicode

Jadi

ialah superset utf8mb4 dan tiada penukaran lain diperlukan kecuali menukar pengekodan kepada utf8. Sudah tentu, untuk menjimatkan ruang, biasanya cukup menggunakan utf8mb4. utf8

Anda boleh menggunakan skrip berikut untuk melihat format pengekodan pangkalan data

1 SHOW VARIABLES WHERE Variable_name LIKE 'character_set_%' OR Variable_name LIKE 'collation%';2 -- 或3 SHOW VARIABLES Like '%char%';

Spesifikasi reka bentuk jadual

1 aplikasi yang berbeza Persatuan harus diminimumkan sebanyak mungkin, dan kunci asing tidak dibenarkan digunakan untuk mengaitkan jadual, memastikan kebebasan antara jadual yang sepadan dengan komponen dan menyediakan kemungkinan membina semula sistem atau struktur jadual. Amalan industri semasa secara amnya melibatkan kawalan program ke atas integriti rujukan.

2. Dari perspektif reka bentuk jadual, reka bentuk pangkalan data tidak seharusnya berdasarkan keseluruhan sistem, tetapi harus berdasarkan pembahagian komponen dalam seni bina sistem, dan reka bentuk pangkalan data harus berdasarkan kepada perniagaan dikendalikan oleh setiap komponen.

3. Jadual mesti mempunyai PK Kelebihan kunci utama ialah pengenalan unik, rujukan berkesan dan perolehan semula yang cekap, jadi secara amnya, cuba untuk mempunyai medan kunci utama.

4. Satu medan hanya mewakili satu makna.

5. Jadual tidak sepatutnya mempunyai lajur pendua.

6. Penggunaan jenis data yang kompleks (susunan, tersuai, dll.) adalah dilarang Penggunaan jenis

bergantung pada situasi. Json

7. Jenis data medan (kunci sambungan) yang memerlukan

mestilah benar-benar konsisten untuk mengelakkan penukaran tersirat. Sebagai contoh, medan yang berkaitan adalah semua jenis int. join

8. Reka bentuk sekurang-kurangnya memenuhi paradigma ketiga dan meminimumkan lebihan data. Sesetengah senario khas membenarkan reka bentuk penyahnormalan, tetapi reka bentuk medan berlebihan perlu dijelaskan semasa semakan projek.

9. Medan TEXT disimpan sebagai sejumlah besar teks dan mesti diletakkan dalam jadual bebas dan dikaitkan dengan jadual utama menggunakan PK. Dilarang menggunakan medan TEXT dan BLOB melainkan ada keperluan khas.

10 Jadual yang perlu memadam (atau memindahkan) data yang telah tamat tempoh secara tetap boleh diselesaikan dengan memisahkan jadual peraturan, mengikut masa Atau gunakan Id sebagai titik pemotongan.

11 Bilangan medan dalam satu jadual tidak boleh terlalu banyak, dan adalah disyorkan untuk tidak melebihi 50 paling banyak. Jadual yang terlalu lebar juga mempunyai kesan yang besar terhadap prestasi.

12 Apabila MySQL memproses jadual besar, prestasinya mula menurun dengan ketara Oleh itu, adalah disyorkan bahawa saiz fizikal satu jadual dihadkan kepada 16GB, dan bilangan baris data dalam jadual dikawal. dalam 2000W.

Peraturan dalam industri ialah prestasi mula menurun dengan ketara melebihi 2000W. Tetapi nilai ini fleksibel, dan anda boleh mengujinya berdasarkan situasi sebenar Contohnya, standard Alibaba ialah 500W, dan Baidu sememangnya 2000W. Malah, sama ada jadual itu luas atau tidak dan ruang yang diduduki oleh satu baris data semuanya memainkan peranan.

13 Jika volum data atau pertumbuhan data adalah besar dalam perancangan awal, maka strategi pemisahan jadual perlu ditambah semasa semakan reka bentuk akan ada artikel khusus kemudian untuk menganalisis amalan pemisahan data: menegak pemisahan Pemisahan (sub-pangkalan data menegak dan sub-jadual menegak), pemisahan mendatar (sub-pangkalan data, sub-jadual dan sub-jadual dalam pangkalan data

14 adalah dilarang sama sekali

Spesifikasi reka bentuk medan

1 INT: Jika tiada keperluan khas, gunakan jenis UNSIGNED INT untuk menyimpan nombor integer selepas medan integer mewakili panjang paparan. Contohnya, id int(11) NOT NULL

2, DATETIME: Gunakan DATETIME untuk semua medan yang perlu tepat pada masa (jam, minit dan saat Jangan gunakan TIMESTAMP). menaip.

Untuk TIMESTAMP, ia menukar masa bertulis daripada zon waktu semasa kepada UTC (Waktu Selaras Sejagat) untuk penyimpanan. Apabila membuat pertanyaan, ia ditukar kepada zon waktu semasa pelanggan dan dikembalikan. Untuk DATETIME, tiada perubahan dibuat, pada asasnya input dan output adalah seperti sedia ada.

Selain itu, julat storan DATETIME juga agak besar:

timestampJulat masa yang boleh disimpan ialah: '1970-01-01 00:00:01.000000 ' hingga '2038- 01-19 03:14:07.999999'.

datetimeJulat masa yang boleh disimpan ialah: '1000-01-01 00:00:00.000000' hingga '9999-12-31 23:59:59.999999'.

Tetapi dalam keadaan istimewa, untuk perniagaan merentas zon waktu, TIMESTAMP adalah lebih sesuai.

3. VARCHAR: Semua rentetan panjang dinamik menggunakan jenis VARCHAR, yang serupa dengan kategori terhad seperti status Rentetan yang boleh menyatakan maksud sebenar tidak boleh digunakan nombor seperti INT; VARCHAR(N),

N mewakili bilangan aksara dan bukannya bilangan bait. Contohnya, VARCHAR(255) boleh menyimpan sehingga 255 aksara (aksara termasuk huruf Inggeris, aksara Cina, aksara khas, dsb.). Tetapi N hendaklah sekecil mungkin, kerana panjang maksimum semua medan VARCHAR dalam jadual MySQL ialah 65535 bait, dan bilangan aksara yang disimpan ditentukan oleh set aksara yang dipilih.

Sebagai contoh, UTF8 memerlukan maksimum 3 bait untuk menyimpan aksara, jadi varchar tidak boleh melebihi 21845 aksara apabila menyimpan aksara yang menduduki 3 bait. Pada masa yang sama, apabila melakukan operasi ingatan seperti menyusun dan mencipta jadual sementara, panjang N akan digunakan untuk memohon ingatan. (Pada prinsipnya, jika tiada keperluan khas, satu medan jenis varchar tidak dibenarkan melebihi 255 aksara)

4 TEXT: Hanya apabila bilangan aksara boleh melebihi 20,000, TEKS jenis boleh digunakan Simpan data aksara, kerana semua pangkalan data MySQL menggunakan set aksara UTF8.

Semua medan yang menggunakan jenis TEXT mesti dipisahkan daripada jadual asal, dan dibentuk menjadi jadual lain secara berasingan daripada kunci utama jadual asal untuk penyimpanan, untuk mengasingkannya daripada medan teks yang besar. Jika tiada keperluan khas, jangan gunakan MEDIUMTEXT, TEXT, LONGTEXT taip

5. Untuk penyimpanan data titik terapung yang tepat, anda perlu menggunakan DECIMAL, dan penggunaan FLOAT dan DOUBLE adalah dilarang sama sekali .

6 Jika tiada keperluan khas, cuba jangan gunakan BLOB taip

7. Jika tiada keperluan khas, disyorkan untuk menggunakan atribut NOT NULL untuk medan, dan nilai lalai boleh digunakan dan bukannya NULL

8. Jenis medan kenaikan automatik mestilah integer dan mestilah UNSIGNED jenis yang disyorkan ialah INT atau BIGINT, dan medan autokenaikan mestilah kunci utama atau sebahagian daripada kunci utama.

Spesifikasi reka bentuk indeks

1 Pembezaan indeks

Indeks mesti dibuat pada lajur dengan selektiviti indeks yang lebih tinggi (diskriminasi), pilih Pengiraan. kaedah indeks ialah: selecttivity = count(distinct c_name)/count(*); Jika hasil diskriminasi kurang daripada 0.2, tidak disyorkan untuk membuat indeks pada lajur ini, jika tidak, ia akan memperlahankan pelaksanaan SQL

2 awalan paling kiri

对于确定需要组成组合索引的多个字段,设计时建议将选择性高的字段靠前放。使用时,组合索引的首字段,必须在where条件中,且需要按照最左前缀规则去匹配。

3、禁止使用外键,可以在程序级别来约束完整性

4、Text类型字段如果需要创建索引,必须使用前缀索引

5、单张表的索引数量理论上应控制在5个以内。经常有大批量插入、更新操作表,应尽量少建索引,索引建立的原则理论上是多读少写的场景。

6、ORDER BYGROUP BYDISTINCT的字段需要添加在索引的后面,形成覆盖索引

7、正确理解和计算索引字段的区分度,文中有计算规则,区分度高的索引,可以快速得定位数据,区分度太低,无法有效的利用索引,可能需要扫描大量数据页,和不使用索引没什么差别。

8、正确理解和计算前缀索引的字段长度,文中有判断规则,合适的长度要保证高的区分度和最恰当的索引存储容量,只有达到最佳状态,才是保证高效率的索引。

9、联合索引注意最左匹配原则:必须按照从左到右的顺序匹配,MySQL会一直向右匹配索引直到遇到范围查询(>、<、betweenlike)然后停止匹配。

如:depno=1 and empname>'' and job=1 如果建立(<code>depno,empname,job)顺序的索引,job是用不到索引的。

10、应需而取策略,查询记录的时候,不要一上来就使用*,只取需要的数据,可能的话尽量只利用索引覆盖,可以减少回表操作,提升效率。

11、正确判断是否使用联合索引(上面联合索引的使用那一小节有说明判断规则),也可以进一步分析到索引下推(IPC),减少回表操作,提升效率。

12、避免索引失效的原则:禁止对索引字段使用函数、运算符操作,会使索引失效。这是实际上就是需要保证索引所对应字段的”干净度“。

13、避免非必要的类型转换,字符串字段使用数值进行比较的时候会导致索引无效。

14、模糊查询’%value%’会使索引无效,变为全表扫描,因为无法判断扫描的区间,但是’value%’是可以有效利用索引。

15、索引覆盖排序字段,这样可以减少排序步骤,提升查询效率

16、尽量的扩展索引,非必要不新建索引。比如表中已经有a的索引,现在要加(a,b)的索引,那么只需要修改原来的索引即可。

举例子:比如一个品牌表,建立的的索引如下,一个主键索引,一个唯一索引

1 PRIMARY KEY (`id`),2 UNIQUE KEY `uni_brand_define` (`app_id`,`define_id`)

当你同事业务代码中的检索语句如下的时候,应该立即警告了,即没有覆盖索引,也没按照最左前缀原则:

1 select brand_id,brand_name from  ds_brand_system where status=?  and define_id=?  and app_id=?

建议改成如下:

1 select brand_id,brand_name from  ds_brand_system where app_id=? and define_id=?  and  status=?

约束设计规范

1、PK应该是有序并且无意义的,由开发人员自定义,尽可能简短,并且是自增序列。

2、表中除PK以外,还存在唯一性约束的,可以在数据库中创建以“uk_”作为前缀的唯一约束索引。

3、PK字段不允许更新。

4、禁止创建外键约束,外键约束由程序控制。

5、如无特殊需要,所有字段必须添加非空约束,即not null

6、如无特殊需要,所有字段必须有默认值。

SQL使用规范

select 检索的规范性

1、尽量避免使用select *,join语句使用select *可能导致只需要访问索引即可完成的查询需要回表取数。

一种是可能取出很多不需要的数据,对于宽表来说,这是灾难;一种是尽可能避免回表,因为取一些根本不需要的数据而回表导致性能低下,是很不合算。

2、严禁使用 select * from t_name ,而不加任何where条件,道理一样,这样会变成全表全字段扫描。

3、MySQL中的text类型字段存储:

3.1、不与其他普通字段存放在一起,因为读取效率低,也会影响其他轻量字段存取效率。

3.2、如果不需要text类型字段,又使用了select *,会让该执行消耗大量io,效率也很低下

4. Fungsi yang berkaitan boleh digunakan pada medan yang diekstrak, tetapi fungsi dengan hasil yang tidak pasti seperti now(), rand(), sysdate() hendaklah dielakkan seboleh-bolehnya medan keadaan penapis dalam Fungsi Di mana, termasuk fungsi penukaran jenis data. Sebilangan besar pengiraan dan penukaran akan menyebabkan ketidakcekapan, yang juga diterangkan dalam indeks.

5. Semua pernyataan pertanyaan paging perlu mempunyai syarat pengisihan, jika tidak, ia akan menyebabkan gangguan

6 perhatian kepada dalam Nombor kurang daripada 300in()/unionor7 adalah dilarang sama sekali menggunakan % awalan untuk pertanyaan awalan kabur: seperti:

; Anda boleh menggunakan % pertanyaan akhiran kabur seperti:

;select a,b,c from t_name where a like ‘%name’select a,b from t_name where a like ‘name%’8 Elakkan menggunakan Subquery, anda boleh mengoptimumkan subquery ke dalam operasi

join Biasanya subquery berada dalam klausa in, dan subquery adalah SQL mudah (tidak termasuk

,

, union, group byklausa), subkueri boleh ditukar kepada pertanyaan berkaitan untuk pengoptimuman. order bylimit Sebab prestasi subkueri yang lemah:

·

Set hasil subkueri tidak boleh menggunakan indeks Biasanya set hasil subkueri akan disimpan dalam jadual sementara . Tiada indeks sama ada dalam jadual sementara memori atau jadual sementara cakera, jadi prestasi pertanyaan akan terjejas pada tahap tertentu

·

Terutamanya untuk subkueri yang mengembalikan set hasil yang agak besar; Lebih besar kesan pada prestasi pertanyaan;

·

Memandangkan subkueri akan menjana sejumlah besar jadual sementara dan tiada indeks, ia akan menggunakan terlalu banyak sumber CPU dan IO dan menjana sejumlah besar daripada pertanyaan Perlahan.

Penyeragaman operasi 1 Dilarang menggunakan pernyataan INSERT tanpa senarai medan

seperti: ; hendaklah menggunakan

.

insert into values ('a','b','c')2. Operasi tulis kelompok besar (insert into t_name(c1,c2,c3) values ('a','b','c');,

,

) perlu dilakukan beberapa kali dalam kelompok UPDATEDELETEINSERT·

Operasi kelompok besar adalah mungkin Ia akan menyebabkan kelewatan tuan-hamba yang serius, terutamanya dalam mod tuan-hamba, operasi kelompok besar boleh menyebabkan kelewatan tuan-hamba yang serius, kerana

perlu membaca log daripada untuk penyegerakan data . slavemasterbinlog·

Apabila log dalam format , sejumlah besar log akan dihasilkan

Atas ialah kandungan terperinci Spesifikasi reka bentuk dan pembangunan MySQ yang paling terperinci [koleksi yang disyorkan]. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Artikel ini dikembalikan pada:learnku.com. Jika ada pelanggaran, sila hubungi admin@php.cn Padam