mysql查詢優(yōu)化器應(yīng)該怎么使用

在開始演示之前，我們先介紹下兩個概念。

專注于為中小企業(yè)提供成都網(wǎng)站設(shè)計、成都網(wǎng)站制作服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)集賢免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千余家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

概念一，數(shù)據(jù)的可選擇性基數(shù)，也就是常說的cardinality值。

查詢優(yōu)化器在生成各種執(zhí)行計劃之前，得先從統(tǒng)計信息中取得相關(guān)數(shù)據(jù)，這樣才能估算每步操作所涉及到的記錄數(shù)，而這個相關(guān)數(shù)據(jù)就是cardinality。簡單來說，就是每個值在每個字段中的唯一值分布狀態(tài)。

比如表t1有100行記錄，其中一列為f1。f1中唯一值的個數(shù)可以是100個，也可以是1個，當(dāng)然也可以是1到100之間的任何一個數(shù)字。這里唯一值越的多少，就是這個列的可選擇基數(shù)。

那看到這里我們就明白了，為什么要在基數(shù)高的字段上建立索引，而基數(shù)低的的字段建立索引反而沒有全表掃描來的快。當(dāng)然這個只是一方面，至于更深入的探討就不在我這篇探討的范圍了。

概念二，關(guān)于HINT的使用。

這里我來說下HINT是什么，在什么時候用。

HINT簡單來說就是在某些特定的場景下人工協(xié)助MySQL優(yōu)化器的工作，使她生成最優(yōu)的執(zhí)行計劃。一般來說，優(yōu)化器的執(zhí)行計劃都是最優(yōu)化的，不過在某些特定場景下，執(zhí)行計劃可能不是最優(yōu)化。

比如：表t1經(jīng)過大量的頻繁更新操作，（UPDATE,DELETE,INSERT），cardinality已經(jīng)很不準(zhǔn)確了，這時候剛好執(zhí)行了一條SQL，那么有可能這條SQL的執(zhí)行計劃就不是最優(yōu)的。為什么說有可能呢？

來看下具體演示

譬如，以下兩條SQL，

A：

select * from t1 where f1 = 20;

B：

select * from t1 where f1 = 30;

如果f1的值剛好頻繁更新的值為30，并且沒有達(dá)到MySQL自動更新cardinality值的臨界值或者說用戶設(shè)置了手動更新又或者用戶減少了sample page等等，那么對這兩條語句來說，可能不準(zhǔn)確的就是B了。

這里順帶說下，MySQL提供了自動更新和手動更新表cardinality值的方法，因篇幅有限，需要的可以查閱手冊。

那回到正題上，MySQL 8.0 帶來了幾個HINT，我今天就舉個index_merge的例子。

示例表結(jié)構(gòu)：

mysql desc t1;+------------+--------------+------+-----+---------+----------------+| Field ? ? ?| Type ? ? ? ? | Null | Key | Default | Extra ? ? ? ? ?|+------------+--------------+------+-----+---------+----------------+| id ? ? ? ? | int(11) ? ? ?| NO ? | PRI | NULL ? ?| auto_increment || rank1 ? ? ?| int(11) ? ? ?| YES ?| MUL | NULL ? ?| ? ? ? ? ? ? ? ?|| rank2 ? ? ?| int(11) ? ? ?| YES ?| MUL | NULL ? ?| ? ? ? ? ? ? ? ?|| log_time ? | datetime ? ? | YES ?| MUL | NULL ? ?| ? ? ? ? ? ? ? ?|| prefix_uid | varchar(100) | YES ?| ? ? | NULL ? ?| ? ? ? ? ? ? ? ?|| desc1 ? ? ?| text ? ? ? ? | YES ?| ? ? | NULL ? ?| ? ? ? ? ? ? ? ?|| rank3 ? ? ?| int(11) ? ? ?| YES ?| MUL | NULL ? ?| ? ? ? ? ? ? ? ?|+------------+--------------+------+-----+---------+----------------+7 rows in set (0.00 sec)

表記錄數(shù)：

mysql select count(*) from t1;+----------+| count(*) |+----------+| ? ?32768 |+----------+1 row in set (0.01 sec)

這里我們兩條經(jīng)典的SQL：

SQL C：

select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D：

select * from t1 where rank1 =100 ?and rank2 =100 ?and rank3 =100;

表t1實際上在rank1,rank2,rank3三列上分別有一個二級索引。

那我們來看SQL C的查詢計劃。

顯然，沒有用到任何索引，掃描的行數(shù)為32034，cost為3243.65。

mysql explain ?format=json select * from t1 ?where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { ?"query_block": { ? ?"select_id": 1, ? ?"cost_info": { ? ? ?"query_cost": "3243.65" ? ?}, ? ?"table": { ? ? ?"table_name": "t1", ? ? ?"access_type": "ALL", ? ? ?"possible_keys": [ ? ? ? ?"idx_rank1", ? ? ? ?"idx_rank2", ? ? ? ?"idx_rank3" ? ? ?], ? ? ?"rows_examined_per_scan": 32034, ? ? ?"rows_produced_per_join": 115, ? ? ?"filtered": "0.36", ? ? ?"cost_info": { ? ? ? ?"read_cost": "3232.07", ? ? ? ?"eval_cost": "11.58", ? ? ? ?"prefix_cost": "3243.65", ? ? ? ?"data_read_per_join": "49K" ? ? ?}, ? ? ?"used_columns": [ ? ? ? ?"id", ? ? ? ?"rank1", ? ? ? ?"rank2", ? ? ? ?"log_time", ? ? ? ?"prefix_uid", ? ? ? ?"desc1", ? ? ? ?"rank3" ? ? ?], ? ? ?"attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" ? ?} ?}}1 row in set, 1 warning (0.00 sec)

我們加上hint給相同的查詢，再次看看查詢計劃。

這個時候用到了index_merge,union了三個列。掃描的行數(shù)為1103，cost為441.09，明顯比之前的快了好幾倍。

mysql explain ?format=json select /*+ index_merge(t1) */ * from t1 ?where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { ?"query_block": { ? ?"select_id": 1, ? ?"cost_info": { ? ? ?"query_cost": "441.09" ? ?}, ? ?"table": { ? ? ?"table_name": "t1", ? ? ?"access_type": "index_merge", ? ? ?"possible_keys": [ ? ? ? ?"idx_rank1", ? ? ? ?"idx_rank2", ? ? ? ?"idx_rank3" ? ? ?], ? ? ?"key": "union(idx_rank1,idx_rank2,idx_rank3)", ? ? ?"key_length": "5,5,5", ? ? ?"rows_examined_per_scan": 1103, ? ? ?"rows_produced_per_join": 1103, ? ? ?"filtered": "100.00", ? ? ?"cost_info": { ? ? ? ?"read_cost": "330.79", ? ? ? ?"eval_cost": "110.30", ? ? ? ?"prefix_cost": "441.09", ? ? ? ?"data_read_per_join": "473K" ? ? ?}, ? ? ?"used_columns": [ ? ? ? ?"id", ? ? ? ?"rank1", ? ? ? ?"rank2", ? ? ? ?"log_time", ? ? ? ?"prefix_uid", ? ? ? ?"desc1", ? ? ? ?"rank3" ? ? ?], ? ? ?"attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" ? ?} ?}}1 row in set, 1 warning (0.00 sec)

我們再看下SQL D的計劃：

不加HINT，

mysql explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { ?"query_block": { ? ?"select_id": 1, ? ?"cost_info": { ? ? ?"query_cost": "534.34" ? ?}, ? ?"table": { ? ? ?"table_name": "t1", ? ? ?"access_type": "ref", ? ? ?"possible_keys": [ ? ? ? ?"idx_rank1", ? ? ? ?"idx_rank2", ? ? ? ?"idx_rank3" ? ? ?], ? ? ?"key": "idx_rank1", ? ? ?"used_key_parts": [ ? ? ? ?"rank1" ? ? ?], ? ? ?"key_length": "5", ? ? ?"ref": [ ? ? ? ?"const" ? ? ?], ? ? ?"rows_examined_per_scan": 555, ? ? ?"rows_produced_per_join": 0, ? ? ?"filtered": "0.07", ? ? ?"cost_info": { ? ? ? ?"read_cost": "478.84", ? ? ? ?"eval_cost": "0.04", ? ? ? ?"prefix_cost": "534.34", ? ? ? ?"data_read_per_join": "176" ? ? ?}, ? ? ?"used_columns": [ ? ? ? ?"id", ? ? ? ?"rank1", ? ? ? ?"rank2", ? ? ? ?"log_time", ? ? ? ?"prefix_uid", ? ? ? ?"desc1", ? ? ? ?"rank3" ? ? ?], ? ? ?"attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))" ? ?} ?}}1 row in set, 1 warning (0.00 sec)

加了HINT，

mysql explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { ?"query_block": { ? ?"select_id": 1, ? ?"cost_info": { ? ? ?"query_cost": "5.23" ? ?}, ? ?"table": { ? ? ?"table_name": "t1", ? ? ?"access_type": "index_merge", ? ? ?"possible_keys": [ ? ? ? ?"idx_rank1", ? ? ? ?"idx_rank2", ? ? ? ?"idx_rank3" ? ? ?], ? ? ?"key": "intersect(idx_rank1,idx_rank2,idx_rank3)", ? ? ?"key_length": "5,5,5", ? ? ?"rows_examined_per_scan": 1, ? ? ?"rows_produced_per_join": 1, ? ? ?"filtered": "100.00", ? ? ?"cost_info": { ? ? ? ?"read_cost": "5.13", ? ? ? ?"eval_cost": "0.10", ? ? ? ?"prefix_cost": "5.23", ? ? ? ?"data_read_per_join": "440" ? ? ?}, ? ? ?"used_columns": [ ? ? ? ?"id", ? ? ? ?"rank1", ? ? ? ?"rank2", ? ? ? ?"log_time", ? ? ? ?"prefix_uid", ? ? ? ?"desc1", ? ? ? ?"rank3" ? ? ?], ? ? ?"attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))" ? ?} ?}}1 row in set, 1 warning (0.00 sec)

對比下以上兩個，加了HINT的比不加HINT的cost小了100倍。

總結(jié)下，就是說表的cardinality值影響這張的查詢計劃，如果這個值沒有正常更新的話，就需要手工加HINT了。相信MySQL未來的版本會帶來更多的HINT。

MySQL 原理與優(yōu)化：原數(shù)據(jù)鎖的應(yīng)用

MySQL 中原數(shù)據(jù)鎖是系統(tǒng)自動控制添加的，對于用戶來說無需顯示調(diào)用，當(dāng)我們使用一張表的時候就會加上原數(shù)據(jù)鎖。

原數(shù)據(jù)鎖的作用是為了保護(hù)表原數(shù)據(jù)的一致性，如果在表上有活動事務(wù)的時候，不可以對元數(shù)據(jù)進(jìn)行寫入操作。也就是為了避免DML 和DDL 之間的沖突，保證讀寫的正確性。

說白了就是， 在對數(shù)據(jù)表進(jìn)行讀寫操作的時候，不能進(jìn)行修改表結(jié)構(gòu)的操作 。

如上圖所示，在執(zhí)行select 操作的時候，MySQL 會自動加上shared_read 鎖，在insert，update， delete 以及 select for update 操作的時候會加上shared_write 鎖，這兩類鎖是兼容的。

在執(zhí)行alter table 操作的時候，會加上 exclusive 鎖，這個鎖與shared_read 和 shared_write 鎖 是互斥的，換句話說在 做查詢和更新表數(shù)據(jù)的時候，是不能夠修改表結(jié)構(gòu) 的。

來看個例子

首先開啟事務(wù)，使用select 語句會針對表加上shared_read的共享鎖

begin;

select * from course;

此時查看原數(shù)據(jù)鎖的信息

select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks;

通過上圖我們可以發(fā)現(xiàn)，course 表加上了shared_read鎖。

接著，開啟另外一個事務(wù)，記住剛才的事務(wù)不要commit

begin;

update course set name = 'Jason' where id =2;

如上圖所示，此時的update 語句可以執(zhí)行成功，并沒有被阻塞。說明select 和update 是不沖突的，他們的鎖是兼容的。

再次查看原數(shù)據(jù)鎖

select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks;

從上面的截圖可以看出，此時原數(shù)據(jù)鎖的表中記錄了兩條記錄分別是針對course 表的shared_read 和 shared_write 鎖，也剛好對應(yīng)我們執(zhí)行的select 和update 操作。

最后，我們再啟動第三個客戶端，并且啟動 第三個事務(wù)，執(zhí)行alter語句,在course 表中加入一個字段hello 如下 。

begin;

alter table course add column hello int;

由于之前的事務(wù)沒有提交所以修改表的操作會被阻塞， 因為shared_read 以及 shared_write 這兩個鎖 與 exclusive之間是互斥的，所以會阻塞 。

此時，回到最開始的兩個客戶端，對兩個事務(wù)進(jìn)行commit 操作，再返回到第三個事務(wù)執(zhí)行的alter 語句出，發(fā)現(xiàn)語句順利執(zhí)行。

怎么進(jìn)行mysql數(shù)據(jù)庫優(yōu)化？

有八個方面可以對mysql進(jìn)行優(yōu)化：

1、選取最適用的字段屬性

MySQL可以很好的支持大數(shù)據(jù)量的存取，但是一般說來，數(shù)據(jù)庫中的表越小，在它上面執(zhí)行的查詢也就會越快。因此，在創(chuàng)建表的時候，為了獲得更好的性能，我們可以將表中字段的寬度設(shè)得盡可能小。

2. 使用連接（JOIN）來代替子查詢(Sub-Queries)

MySQL從4.1開始支持SQL的子查詢。這個技術(shù)可以使用SELECT語句來創(chuàng)建一個單列的查詢結(jié)果，然后把這個結(jié)果作為過濾條件用在另一個查詢中。

3、使用聯(lián)合(UNION)來代替手動創(chuàng)建的臨時表

MySQL從4.0的版本開始支持union查詢，它可以把需要使用臨時表的兩條或更多的select查詢合并的一個查詢中。在客戶端的查詢會話結(jié)束的時候，臨時表會被自動刪除，從而保證數(shù)據(jù)庫整齊、高效。

4、事務(wù)

盡管我們可以使用子查詢（Sub-Queries）、連接（JOIN）和聯(lián)合（UNION）來創(chuàng)建各種各樣的查詢，但不是所有的數(shù)據(jù)庫操作都可以只用一條或少數(shù)幾條SQL語句就可以完成的。更多的時候是需要用到一系列的語句來完成某種工作。但是在這種情況下，當(dāng)這個語句塊中的某一條語句運行出錯的時候，整個語句塊的操作就會變得不確定起來。設(shè)想一下，要把某個數(shù)據(jù)同時插入兩個相關(guān)聯(lián)的表中，可能會出現(xiàn)這樣的情況：第一個表中成功更新后，數(shù)據(jù)庫突然出現(xiàn)意外狀況，造成第二個表中的操作沒有完成，這樣，就會造成數(shù)據(jù)的不完整，甚至?xí)茐臄?shù)據(jù)庫中的數(shù)據(jù)。要避免這種情況，就應(yīng)該使用事務(wù)，它的作用是：要么語句塊中每條語句都操作成功，要么都失敗

5、鎖定表

盡管事務(wù)是維護(hù)數(shù)據(jù)庫完整性的一個非常好的方法，但卻因為它的獨占性，有時會影響數(shù)據(jù)庫的性能，尤其是在很大的應(yīng)用系統(tǒng)中。由于在事務(wù)執(zhí)行的過程中，數(shù)據(jù)庫將會被鎖定，因此其它的用戶請求只能暫時等待直到該事務(wù)結(jié)束。其實，有些情況下我們可以通過鎖定表的方法來獲得更好的性能。

6、使用外鍵

鎖定表的方法可以維護(hù)數(shù)據(jù)的完整性，但是它卻不能保證數(shù)據(jù)的關(guān)聯(lián)性。這個時候我們就可以使用外鍵。

7、使用索引

索引是提高數(shù)據(jù)庫性能的常用方法，它可以令數(shù)據(jù)庫服務(wù)器以比沒有索引快得多的速度檢索特定的行，尤其是在查詢語句當(dāng)中包含有MAX(),MIN()和ORDERBY這些命令的時候，性能提高更為明顯。

8、優(yōu)化的查詢語句

絕大多數(shù)情況下，使用索引可以提高查詢的速度，但如果SQL語句使用不恰當(dāng)?shù)脑挘饕龑o法發(fā)揮它應(yīng)有的作用。

當(dāng)前標(biāo)題：mysql怎么使用鎖優(yōu)化 mysql鎖有幾種方式
網(wǎng)站地址：http://www.chinadenli.net/article42/dosieec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、軟件開發(fā)、App開發(fā)、微信公眾號、微信小程序、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)