cari
Rumahpangkalan datatutorial mysqlParallel Query for MySQL with Shard-Query_MySQL

While Shard-Query can work over multiple nodes, this blog post focuses on using Shard-Query with a single node.  Shard-Query can add parallelism to queries which use partitionedtables.  Very large tables can often be partitioned fairly easily. Shard-Query can leverage partitioning to add paralellism, because each partition can be queried independently. Because MySQL 5.6 supports the partition hint, Shard-Query can add parallelism to any partitioning method (even subpartioning) on 5.6 but it is limited to RANGE/LIST partitioning methods on early versions.

The output from Shard-Query is from the commandline client, but you can use MySQL proxy to communicate with Shard-Query too.

In the examples I am going to use the schema from the Star Schema Benchmark.  I generated data for scale factor 10, which means about 6GB of data in the largest table. I am going to show a few different queries, and explain how Shard-Query executes them in parallel.

Here is the DDL for the lineorder table, which I will use for the demo queries:

CREATE TABLE IF NOT EXISTS lineorder( LO_OrderKey bigint not null, LO_LineNumber tinyint not null, LO_CustKey int not null, LO_PartKey int not null, LO_SuppKey int not null, LO_OrderDateKey int not null, LO_OrderPriority varchar(15), LO_ShipPriority char(1), LO_Quantity tinyint, LO_ExtendedPrice decimal, LO_OrdTotalPrice decimal, LO_Discount decimal, LO_Revenue decimal, LO_SupplyCost decimal, LO_Tax tinyint, LO_CommitDateKey int not null, LO_ShipMode varchar(10), primary key(LO_OrderDateKey,LO_PartKey,LO_SuppKey,LO_Custkey,LO_OrderKey,LO_LineNumber)) PARTITION BY HASH(LO_OrderDateKey) PARTITIONS 8;

CREATETABLEIFNOTEXISTSlineorder

(

LO_OrderKeybigintnotnull,

LO_LineNumbertinyintnotnull,

LO_CustKeyintnotnull,

LO_PartKeyintnotnull,

LO_SuppKeyintnotnull,

LO_OrderDateKeyintnotnull,

LO_OrderPriorityvarchar(15),

LO_ShipPrioritychar(1),

LO_Quantitytinyint,

LO_ExtendedPricedecimal,

LO_OrdTotalPricedecimal,

LO_Discountdecimal,

LO_Revenuedecimal,

LO_SupplyCostdecimal,

LO_Taxtinyint,

LO_CommitDateKeyintnotnull,

LO_ShipModevarchar(10),

primarykey(LO_OrderDateKey,LO_PartKey,LO_SuppKey,LO_Custkey,LO_OrderKey,LO_LineNumber)

)PARTITIONBYHASH(LO_OrderDateKey)PARTITIONS8;

Notice that the lineorder table is partitioned by HASH(LO_OrderDateKey) into 8 partitions.  I used 8 partitions and my test box has 4 cores. It does not hurt to have more partitions than cores. A number of partitions that is two or three times the number of cores generally works best because it keeps each partition small, and smaller partitions are faster to scan. If you have a very large table, a larger number of partitions may be acceptable. Shard-Query will submit a query to Gearman for each partition, and the number of Gearman workers controls the parallelism.

The SQL for the first demo is:

SELECT COUNT(DISTINCT LO_OrderDateKey) FROM lineorder;

SELECTCOUNT(DISTINCTLO_OrderDateKey)FROMlineorder;

Here is the explain from regular MySQL:

mysql> explain select count(distinct LO_OrderDateKey) from lineorder/G*************************** 1. row *************************** id: 1select_type: SIMPLEtable: lineorder type: indexpossible_keys: PRIMARYkey: PRIMARYkey_len: 25ref: NULL rows: 58922188Extra: Using index1 row in set (0.00 sec)

mysql>explainselectcount(distinctLO_OrderDateKey)fromlineorder/G

***************************1.row***************************

          id:1

  select_type:SIMPLE

        table:lineorder

        type:index

possible_keys:PRIMARY

          key:PRIMARY

      key_len:25

          ref:NULL

        rows:58922188

        Extra:Usingindex

1rowinset(0.00sec)

So it is basically a full table scan. It takes a long time:

mysql> select count(distinct LO_OrderDateKey) from lineorder;+---------------------------------+| count(distinct LO_OrderDateKey) |+---------------------------------+|2406 |+---------------------------------+1 row in set (4 min 48.63 sec)

mysql>selectcount(distinctLO_OrderDateKey)fromlineorder;

+---------------------------------+

|count(distinctLO_OrderDateKey)|

+---------------------------------+

|                            2406|

+---------------------------------+

1rowinset(4min48.63sec)

Shard-Query executes this query differently from MySQL. It sends a query to each partition, in parallel like the following queries:

Array([0] => SELECT LO_OrderDateKey AS expr_2839651562FROM lineorderPARTITION(p0)AS `lineorder` WHERE 1=1AND 1=1GROUP BY LO_OrderDateKey[1] => SELECT LO_OrderDateKey AS expr_2839651562FROM lineorderPARTITION(p1)AS `lineorder` WHERE 1=1AND 1=1GROUP BY LO_OrderDateKey[2] => SELECT LO_OrderDateKey AS expr_2839651562FROM lineorderPARTITION(p2)AS `lineorder` WHERE 1=1AND 1=1GROUP BY LO_OrderDateKey[3] => SELECT LO_OrderDateKey AS expr_2839651562FROM lineorderPARTITION(p3)AS `lineorder` WHERE 1=1AND 1=1GROUP BY LO_OrderDateKey[4] => SELECT LO_OrderDateKey AS expr_2839651562FROM lineorderPARTITION(p4)AS `lineorder` WHERE 1=1AND 1=1GROUP BY LO_OrderDateKey[5] => SELECT LO_OrderDateKey AS expr_2839651562FROM lineorderPARTITION(p5)AS `lineorder` WHERE 1=1AND 1=1GROUP BY LO_OrderDateKey[6] => SELECT LO_OrderDateKey AS expr_2839651562FROM lineorderPARTITION(p6)AS `lineorder` WHERE 1=1AND 1=1GROUP BY LO_OrderDateKey[7] => SELECT LO_OrderDateKey AS expr_2839651562FROM lineorderPARTITION(p7)AS `lineorder` WHERE 1=1AND 1=1GROUP BY LO_OrderDateKey)
Array(

    [0]=>SELECTLO_OrderDateKeyASexpr_2839651562

FROMlineorder  PARTITION(p0)  AS`lineorder`  WHERE1=1  AND1=1  GROUPBYLO_OrderDateKey

    [1]=>SELECTLO_OrderDateKeyASexpr_2839651562

FROMlineorder  PARTITION(p1)  AS`lineorder`  WHERE1=1  AND1=1  GROUPBYLO_OrderDateKey

    [2]=>SELECTLO_OrderDateKeyASexpr_2839651562

FROMlineorder  PARTITION(p2)  AS`lineorder`  WHERE1=1  AND1=1  GROUPBYLO_OrderDateKey

    [3]=>SELECTLO_OrderDateKeyASexpr_2839651562

FROMlineorder  PARTITION(p3)  AS`lineorder`  WHERE1=1  AND1=1  GROUPBYLO_OrderDateKey

    [4]=>SELECTLO_OrderDateKeyASexpr_2839651562

FROMlineorder  PARTITION(p4)  AS`lineorder`  WHERE1=1  AND1=1  GROUPBYLO_OrderDateKey

    [5]=>SELECTLO_OrderDateKeyASexpr_2839651562

FROMlineorder  PARTITION(p5)  AS`lineorder`  WHERE1=1  AND1=1  GROUPBYLO_OrderDateKey

    [6]=>SELECTLO_OrderDateKeyASexpr_2839651562

FROMlineorder  PARTITION(p6)  AS`lineorder`  WHERE1=1  AND1=1  GROUPBYLO_OrderDateKey

    [7]=>SELECTLO_OrderDateKeyASexpr_2839651562

FROMlineorder  PARTITION(p7)  AS`lineorder`  WHERE1=1  AND1=1  GROUPBYLO_OrderDateKey

)

You will notice that there is one query for each partition.  Those queries will be sent to Gearman and executed in parallel by as many Gearman workers as possible (in this case 4.)  The output of the queries go into a coordinator table, and then another query does a final aggregation.  That query looks like this:

SELECT COUNT(distinct expr_2839651562) AS `count`FROM `aggregation_tmp_73522490`

SELECTCOUNT(distinctexpr_2839651562)AS`count`

FROM`aggregation_tmp_73522490`

The Shard-Query time:

select count(distinct LO_OrderDateKey) from lineorder;Array([count ] => 2406)1 rows returnedExec time: 0.10923719406128

selectcount(distinctLO_OrderDateKey)fromlineorder;

Array(

    [count]=>2406

)1rowsreturned

Exectime:0.10923719406128

That isn’t a typo, it really issub-secondcompared tominutesin regular MySQL.

This is because Shard-Query usesGROUP BYto answer this query and a loose index scanof the PRIMARY KEY is possible:

mysql> explain partitions SELECT LO_OrderDateKey AS expr_2839651562-> FROM lineorderPARTITION(p7)AS `lineorder` WHERE 1=1AND 1=1GROUP BY LO_OrderDateKey-> /G*************************** 1. row *************************** id: 1select_type: SIMPLEtable: lineorder partitions: p7 type: rangepossible_keys: PRIMARYkey: PRIMARYkey_len: 4ref: NULL rows: 80108Extra: Using index for group-by1 row in set (0.00 sec)

mysql>explainpartitionsSELECTLO_OrderDateKeyASexpr_2839651562

    ->FROMlineorder  PARTITION(p7)  AS`lineorder`  WHERE1=1  AND1=1  GROUPBYLO_OrderDateKey

    ->/G

***************************1.row***************************

          id:1

  select_type:SIMPLE

        table:lineorder

  partitions:p7

        type:range

possible_keys:PRIMARY

          key:PRIMARY

      key_len:4

          ref:NULL

        rows:80108

        Extra:Usingindexforgroup-by

1rowinset(0.00sec)

Next another simple query will be tested, first on regular MySQL:

mysql> select count(*) from lineorder;+----------+| count(*) |+----------+| 59986052 |+----------+1 row in set (4 min 8.70 sec)

mysql>selectcount(*)fromlineorder;

+----------+|count(*)|+----------+|59986052|+----------+

1rowinset(4min8.70sec)

Again, the EXPLAIN shows a full table scan:

mysql> explain select count(*) from lineorder/G*************************** 1. row *************************** id: 1select_type: SIMPLEtable: lineorder type: indexpossible_keys: NULLkey: PRIMARYkey_len: 25ref: NULL rows: 58922188Extra: Using index1 row in set (0.00 sec)

mysql>explainselectcount(*)fromlineorder/G

***************************1.row***************************

          id:1

  select_type:SIMPLE

        table:lineorder

        type:index

possible_keys:NULL

          key:PRIMARY

      key_len:25

          ref:NULL

        rows:58922188

        Extra:Usingindex

1rowinset(0.00sec)

Now, Shard-Query can’t do anything special to speed up this query, except to execute it in parallel, similar to the first query:

[0] => SELECT COUNT(*) AS expr_3190753946FROM lineorder PARTITION(p0) AS `lineorder` WHERE 1=1 AND 1=1[1] => SELECT COUNT(*) AS expr_3190753946FROM lineorder PARTITION(p1) AS `lineorder` WHERE 1=1 AND 1=1[2] => SELECT COUNT(*) AS expr_3190753946FROM lineorder PARTITION(p2) AS `lineorder` WHERE 1=1 AND 1=1[3] => SELECT COUNT(*) AS expr_3190753946FROM lineorder PARTITION(p3) AS `lineorder` WHERE 1=1 AND 1=1...

[0]=>SELECTCOUNT(*)ASexpr_3190753946

FROMlineorderPARTITION(p0)AS`lineorder`WHERE1=1AND1=1

[1]=>SELECTCOUNT(*)ASexpr_3190753946

FROMlineorderPARTITION(p1)AS`lineorder`WHERE1=1AND1=1

[2]=>SELECTCOUNT(*)ASexpr_3190753946

FROMlineorderPARTITION(p2)AS`lineorder`WHERE1=1AND1=1

[3]=>SELECTCOUNT(*)ASexpr_3190753946

FROMlineorderPARTITION(p3)AS`lineorder`WHERE1=1AND1=1

...

The aggregation SQL is similar, but this time the aggregate function is changed to SUM to combine the COUNT from each partition:

SELECT SUM(expr_3190753946) AS ` count `FROM `aggregation_tmp_51969525`

SELECTSUM(expr_3190753946)AS`count`

FROM`aggregation_tmp_51969525`

And the query is quite a bit faster at 140.24 second compared with MySQL’s 248.7 second result:

Array([count ] => 59986052)1 rows returnedExec time: 140.24419403076
Array(

[count]=>59986052

)1rowsreturned

Exectime:140.24419403076

Finally, I want to look at a more complex query that uses joins and aggregation.

mysql> explain select d_year, c_nation,sum(lo_revenue - lo_supplycost) as profitfrom lineorderjoin dim_dateon lo_orderdatekey = d_datekeyjoin customeron lo_custkey = c_customerkeyjoin supplieron lo_suppkey = s_suppkeyjoin parton lo_partkey = p_partkeywherec_region = 'AMERICA'and s_region = 'AMERICA'and (p_mfgr = 'MFGR#1'or p_mfgr = 'MFGR#2')group by d_year, c_nationorder by d_year, c_nation;+----+-------------+-----------+--------+---------------+---------+---------+--------------------------+------+---------------------------------+| id | select_type | table | type | possible_keys | key | key_len | ref| rows | Extra |+----+-------------+-----------+--------+---------------+---------+---------+--------------------------+------+---------------------------------+|1 | SIMPLE| dim_date| ALL| PRIMARY | NULL| NULL| NULL |5 | Using temporary; Using filesort ||1 | SIMPLE| lineorder | ref| PRIMARY | PRIMARY | 4 | ssb.dim_date.D_DateKey | 89 | NULL||1 | SIMPLE| supplier| eq_ref | PRIMARY | PRIMARY | 4 | ssb.lineorder.LO_SuppKey |1 | Using where ||1 | SIMPLE| customer| eq_ref | PRIMARY | PRIMARY | 4 | ssb.lineorder.LO_CustKey |1 | Using where ||1 | SIMPLE| part| eq_ref | PRIMARY | PRIMARY | 4 | ssb.lineorder.LO_PartKey |1 | Using where |+----+-------------+-----------+--------+---------------+---------+---------+--------------------------+------+---------------------------------+5 rows in set (0.01 sec)

mysql>explainselectd_year,c_nation,  sum(lo_revenue-lo_supplycost)asprofit  fromlineorder  

joindim_date  onlo_orderdatekey=d_datekey  

joincustomer  onlo_custkey=c_customerkey  

joinsupplier  onlo_suppkey=s_suppkey  

joinpart  onlo_partkey=p_partkey  

where  c_region='AMERICA'  ands_region='AMERICA'  

and(p_mfgr='MFGR#1'  orp_mfgr='MFGR#2')  

groupbyd_year,c_nation  orderbyd_year,c_nation;

+----+-------------+-----------+--------+---------------+---------+---------+--------------------------+------+---------------------------------+

|id|select_type|table    |type  |possible_keys|key    |key_len|ref                      |rows|Extra                          |

+----+-------------+-----------+--------+---------------+---------+---------+--------------------------+------+---------------------------------+

|  1|SIMPLE      |dim_date  |ALL    |PRIMARY      |NULL    |NULL    |NULL                    |    5|Usingtemporary;Usingfilesort|

|  1|SIMPLE      |lineorder|ref    |PRIMARY      |PRIMARY|4      |ssb.dim_date.D_DateKey  |  89|NULL                            |

|  1|SIMPLE      |supplier  |eq_ref|PRIMARY      |PRIMARY|4      |ssb.lineorder.LO_SuppKey|    1|Usingwhere                    |

|  1|SIMPLE      |customer  |eq_ref|PRIMARY      |PRIMARY|4      |ssb.lineorder.LO_CustKey|    1|Usingwhere                    |

|  1|SIMPLE      |part      |eq_ref|PRIMARY      |PRIMARY|4      |ssb.lineorder.LO_PartKey|    1|Usingwhere                    |

+----+-------------+-----------+--------+---------------+---------+---------+--------------------------+------+---------------------------------+

5rowsinset(0.01sec)

Here is the query on regular MySQL:

mysql> select d_year, c_nation,sum(lo_revenue - lo_supplycost) as profitfrom lineorderjoin dim_dateon lo_orderdatekey = d_datekeyjoin customeron lo_custkey = c_customerkeyjoin supplieron lo_suppkey = s_suppkeyjoin parton lo_partkey = p_partkeywherec_region = 'AMERICA'and s_region = 'AMERICA'and (p_mfgr = 'MFGR#1'or p_mfgr = 'MFGR#2')group by d_year, c_nationorder by d_year, c_nation;+--------+---------------+--------------+| d_year | c_nation| profit |+--------+---------------+--------------+| 1992 | ARGENTINA | 102741829748 |...| 1998 | UNITED STATES |61345891337 |+--------+---------------+--------------+35 rows in set (11 min 56.79 sec)

mysql>selectd_year,c_nation,  sum(lo_revenue-lo_supplycost)asprofit  fromlineorder  joindim_date  onlo_orderdatekey=d_datekey  joincustomer  onlo_custkey=c_customerkey  joinsupplier  onlo_suppkey=s_suppkey  joinpart  onlo_partkey=p_partkey  where  c_region='AMERICA'  ands_region='AMERICA'  and(p_mfgr='MFGR#1'  orp_mfgr='MFGR#2')  groupbyd_year,c_nation  orderbyd_year,c_nation;

+--------+---------------+--------------+

|d_year|c_nation      |profit      |

+--------+---------------+--------------+

|  1992|ARGENTINA    |102741829748|

...

|  1998|UNITEDSTATES|  61345891337|

+--------+---------------+--------------+

35rowsinset(11min56.79sec)

Again, Shard-Query splits up the query to run over each partition (I won’t bore you with the details) and it executes the query faster than MySQL, in 343.3 second compared to ~720:

Array([d_year] => 1998[c_nation] => UNITED STATES[profit] => 61345891337)35 rows returnedExec time: 343.29854893684
Array(

    [d_year]=>1998

    [c_nation]=>UNITEDSTATES

    [profit]=>61345891337

)35rowsreturned

Exectime:343.29854893684

I hope you see how using Shard-Query can speed up queries without using sharding, on just a single server. All you really need to do is add partitioning.

You can get Shard-Query from GitHub at http://github.com/greenlion/swanhart-tools

Please note: Configure and install Shard-Query as normal, but simply use one node and set thecolumnoption (the shard column) to “nocolumn” or false, because you are not required to use a shard column if you are not sharding.

Kenyataan
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
MySQL: Pengenalan kepada pangkalan data paling popular di duniaMySQL: Pengenalan kepada pangkalan data paling popular di duniaApr 12, 2025 am 12:18 AM

MySQL adalah sistem pengurusan pangkalan data relasi sumber terbuka, terutamanya digunakan untuk menyimpan dan mengambil data dengan cepat dan boleh dipercayai. Prinsip kerjanya termasuk permintaan pelanggan, resolusi pertanyaan, pelaksanaan pertanyaan dan hasil pulangan. Contoh penggunaan termasuk membuat jadual, memasukkan dan menanyakan data, dan ciri -ciri canggih seperti Operasi Join. Kesalahan umum melibatkan sintaks SQL, jenis data, dan keizinan, dan cadangan pengoptimuman termasuk penggunaan indeks, pertanyaan yang dioptimumkan, dan pembahagian jadual.

Kepentingan MySQL: Penyimpanan Data dan PengurusanKepentingan MySQL: Penyimpanan Data dan PengurusanApr 12, 2025 am 12:18 AM

MySQL adalah sistem pengurusan pangkalan data sumber terbuka yang sesuai untuk penyimpanan data, pengurusan, pertanyaan dan keselamatan. 1. Ia menyokong pelbagai sistem operasi dan digunakan secara meluas dalam aplikasi web dan bidang lain. 2. Melalui seni bina pelanggan-pelayan dan enjin penyimpanan yang berbeza, MySQL memproses data dengan cekap. 3. Penggunaan asas termasuk membuat pangkalan data dan jadual, memasukkan, menanyakan dan mengemas kini data. 4. Penggunaan lanjutan melibatkan pertanyaan kompleks dan prosedur yang disimpan. 5. Kesilapan umum boleh disahpepijat melalui pernyataan yang dijelaskan. 6. Pengoptimuman Prestasi termasuk penggunaan indeks rasional dan pernyataan pertanyaan yang dioptimumkan.

Mengapa menggunakan mysql? Faedah dan kelebihanMengapa menggunakan mysql? Faedah dan kelebihanApr 12, 2025 am 12:17 AM

MySQL dipilih untuk prestasi, kebolehpercayaan, kemudahan penggunaan, dan sokongan komuniti. 1.MYSQL Menyediakan fungsi penyimpanan dan pengambilan data yang cekap, menyokong pelbagai jenis data dan operasi pertanyaan lanjutan. 2. Mengamalkan seni bina pelanggan-pelayan dan enjin penyimpanan berganda untuk menyokong urus niaga dan pengoptimuman pertanyaan. 3. Mudah digunakan, menyokong pelbagai sistem operasi dan bahasa pengaturcaraan. 4. Mempunyai sokongan komuniti yang kuat dan menyediakan sumber dan penyelesaian yang kaya.

Huraikan mekanisme penguncian InnoDB (kunci yang dikongsi, kunci eksklusif, kunci niat, kunci rekod, kunci jurang, kunci seterusnya).Huraikan mekanisme penguncian InnoDB (kunci yang dikongsi, kunci eksklusif, kunci niat, kunci rekod, kunci jurang, kunci seterusnya).Apr 12, 2025 am 12:16 AM

Mekanisme kunci InnoDB termasuk kunci bersama, kunci eksklusif, kunci niat, kunci rekod, kunci jurang dan kunci utama seterusnya. 1. Kunci dikongsi membolehkan urus niaga membaca data tanpa menghalang urus niaga lain dari membaca. 2. Kunci eksklusif menghalang urus niaga lain daripada membaca dan mengubah suai data. 3. Niat Kunci mengoptimumkan kecekapan kunci. 4. Rekod Rekod Kunci Kunci Rekod. 5. Gap Lock Locks Index Rakaman Gap. 6. Kunci kunci seterusnya adalah gabungan kunci rekod dan kunci jurang untuk memastikan konsistensi data.

Apakah sebab -sebab biasa prestasi pertanyaan MySQL yang lemah?Apakah sebab -sebab biasa prestasi pertanyaan MySQL yang lemah?Apr 12, 2025 am 12:11 AM

Sebab -sebab utama prestasi pertanyaan MySQL yang lemah termasuk tidak menggunakan indeks, pemilihan pelan pelaksanaan yang salah oleh pengoptimasi pertanyaan, reka bentuk jadual yang tidak munasabah, jumlah data yang berlebihan dan persaingan kunci. 1. Tiada indeks menyebabkan pertanyaan perlahan, dan menambah indeks dapat meningkatkan prestasi dengan ketara. 2. Gunakan perintah Jelaskan untuk menganalisis pelan pertanyaan dan cari ralat pengoptimuman. 3. Membina semula struktur meja dan mengoptimumkan keadaan gabungan dapat meningkatkan masalah reka bentuk jadual. 4. Apabila jumlah data adalah besar, pembahagian dan strategi bahagian meja diterima pakai. 5. Dalam persekitaran konkurensi yang tinggi, mengoptimumkan urus niaga dan strategi mengunci dapat mengurangkan persaingan kunci.

Bilakah anda harus menggunakan indeks komposit berbanding indeks lajur tunggal?Bilakah anda harus menggunakan indeks komposit berbanding indeks lajur tunggal?Apr 11, 2025 am 12:06 AM

Dalam pengoptimuman pangkalan data, strategi pengindeksan hendaklah dipilih mengikut keperluan pertanyaan: 1. Apabila pertanyaan melibatkan pelbagai lajur dan urutan syarat ditetapkan, gunakan indeks komposit; 2. Apabila pertanyaan melibatkan pelbagai lajur tetapi urutan syarat tidak ditetapkan, gunakan pelbagai indeks lajur tunggal. Indeks komposit sesuai untuk mengoptimumkan pertanyaan berbilang lajur, manakala indeks lajur tunggal sesuai untuk pertanyaan tunggal lajur.

Bagaimana untuk mengenal pasti dan mengoptimumkan pertanyaan perlahan di MySQL? (Log pertanyaan perlahan, prestasi_schema)Bagaimana untuk mengenal pasti dan mengoptimumkan pertanyaan perlahan di MySQL? (Log pertanyaan perlahan, prestasi_schema)Apr 10, 2025 am 09:36 AM

Untuk mengoptimumkan pertanyaan perlahan MySQL, SlowQuerylog dan Performance_Schema perlu digunakan: 1. Dayakan SlowQueryLog dan tetapkan ambang untuk merakam pertanyaan perlahan; 2. Gunakan Performance_Schema untuk menganalisis butiran pelaksanaan pertanyaan, cari kesesakan prestasi dan mengoptimumkan.

MySQL dan SQL: Kemahiran Penting untuk PemajuMySQL dan SQL: Kemahiran Penting untuk PemajuApr 10, 2025 am 09:30 AM

MySQL dan SQL adalah kemahiran penting untuk pemaju. 1.MYSQL adalah sistem pengurusan pangkalan data sumber terbuka, dan SQL adalah bahasa standard yang digunakan untuk mengurus dan mengendalikan pangkalan data. 2.MYSQL menyokong pelbagai enjin penyimpanan melalui penyimpanan data yang cekap dan fungsi pengambilan semula, dan SQL melengkapkan operasi data yang kompleks melalui pernyataan mudah. 3. Contoh penggunaan termasuk pertanyaan asas dan pertanyaan lanjutan, seperti penapisan dan penyortiran mengikut keadaan. 4. Kesilapan umum termasuk kesilapan sintaks dan isu -isu prestasi, yang boleh dioptimumkan dengan memeriksa penyataan SQL dan menggunakan perintah menjelaskan. 5. Teknik pengoptimuman prestasi termasuk menggunakan indeks, mengelakkan pengimbasan jadual penuh, mengoptimumkan operasi menyertai dan meningkatkan kebolehbacaan kod.

See all articles

Alat AI Hot

Undresser.AI Undress

Undresser.AI Undress

Apl berkuasa AI untuk mencipta foto bogel yang realistik

AI Clothes Remover

AI Clothes Remover

Alat AI dalam talian untuk mengeluarkan pakaian daripada foto.

Undress AI Tool

Undress AI Tool

Gambar buka pakaian secara percuma

Clothoff.io

Clothoff.io

Penyingkiran pakaian AI

AI Hentai Generator

AI Hentai Generator

Menjana ai hentai secara percuma.

Artikel Panas

R.E.P.O. Kristal tenaga dijelaskan dan apa yang mereka lakukan (kristal kuning)
3 minggu yang laluBy尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. Tetapan grafik terbaik
3 minggu yang laluBy尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. Cara Memperbaiki Audio Jika anda tidak dapat mendengar sesiapa
3 minggu yang laluBy尊渡假赌尊渡假赌尊渡假赌
WWE 2K25: Cara Membuka Segala -galanya Di Myrise
4 minggu yang laluBy尊渡假赌尊渡假赌尊渡假赌

Alat panas

Hantar Studio 13.0.1

Hantar Studio 13.0.1

Persekitaran pembangunan bersepadu PHP yang berkuasa

Versi Mac WebStorm

Versi Mac WebStorm

Alat pembangunan JavaScript yang berguna

MantisBT

MantisBT

Mantis ialah alat pengesan kecacatan berasaskan web yang mudah digunakan yang direka untuk membantu dalam pengesanan kecacatan produk. Ia memerlukan PHP, MySQL dan pelayan web. Lihat perkhidmatan demo dan pengehosan kami.

SublimeText3 Linux versi baharu

SublimeText3 Linux versi baharu

SublimeText3 Linux versi terkini

Notepad++7.3.1

Notepad++7.3.1

Editor kod yang mudah digunakan dan percuma