2. 程式人生 > >讓天下沒有難用的資料庫 » Mysql中對primary key一點選擇改變

讓天下沒有難用的資料庫 » Mysql中對primary key一點選擇改變

阿新 • • 發佈：2018-12-29

在5.1.46中優化器在對primary key的選擇上做了一點改動：

Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the full row length for a clustered primary key, as in InnoDB. Secondary covering indexes will now be preferred, making full table scans less likely。

該版本中增加了find_shortest_key函式，該函式的作用可以認為是選擇最小key length的

索引來滿足我們的查詢。

該函式是怎麼工作的：

What find_shortest_key should do is the following. If the primary key is a covering index

and is clustered, like in MyISAM, then the behavior today should remain the same. If the

primary key is clustered, like in InnoDB, then it should not consider using the primary

key because then the storage engine will have to scan through much more data.

呼叫Primary_key_is_clustered()，當返回值為true，執行find_shortest_key：選擇key length最小的覆蓋索引（Secondary covering indexes），然後來滿足查詢。

首先在5.1.45中測試：

$mysql -V

mysql  Ver 14.14 Distrib 5.1.45, for unknown-linux-gnu (x86_64) using  EditLine wrapper

[email protected] 03:49:45>create table test(id int,name varchar(20),name2 varchar(20),d datetime,primary key(id)) engine=innodb;

Query OK, 0 rows affected (0.16 sec)

[email protected] 03:49:47>insert into test values(1,’xc’,’sds’,now()),(2,’xcx’,’dd’,now()),(3,’sdds’,’ddd’,now()),(4,’sdsdf’,’dsd’,now()),(5,’sdsdaa’,’sds’,now());

Query OK, 5 rows affected (0.00 sec)

Records: 5  Duplicates: 0  Warnings: 0

[email protected] 03:49:51>

[email protected] 03:49:51>insert into test values(6,’xce’,’sdsd’,now()),(7,’xcx’,’sdsd’,now()),(8,’sdds’,’sds’,now()),(9,’sdsdsdf’,’sdsdsd’,now()),(10,’sdssdfdaa’,’sdsdsd’,now());

Query OK, 5 rows affected (0.00 sec)

Records: 5  Duplicates: 0  Warnings: 0

建立索引ind_1：

[email protected] 03:49:53>alter table test add index ind_1(name,d);

Query OK, 0 rows affected (0.09 sec)

Records: 0  Duplicates: 0  Warnings: 0

[email protected] 03:50:08>explain select count(*) from test;

+—-+————-+——-+——-+—————+———+———+——+——+————-+

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

+—-+————-+——-+——-+—————+———+———+——+——+————-+

|  1 | SIMPLE      | test  | index | NULL          | PRIMARY | 4       | NULL |   10 | Using index |

+—-+————-+——-+——-+—————+———+———+——+——+————-+

1 row in set (0.00 sec)

新增ind_2：

[email protected] 08:04:35>alter table test add index ind_2(d);

Query OK, 0 rows affected (0.07 sec)

Records: 0  Duplicates: 0  Warnings: 0

[email protected] 08:04:45>explain select count(*) from test;

+—-+————-+——-+——-+—————+———+———+——+——+————-+

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

+—-+————-+——-+——-+—————+———+———+——+——+————-+

|  1 | SIMPLE      | test  | index | NULL          | PRIMARY | 4       | NULL |   10 | Using index |

+—-+————-+——-+——-+—————+———+———+——+——+————-+

1 row in set (0.00 sec)

上面的版本【5.1.45】中，可以看到優化器選擇使用主鍵來完成掃描，並沒有使用ind_1，ind_2來完成查詢；

接下來是：5.1.48

$mysql -V

mysql  Ver 14.14 Distrib 5.1.48, for unknown-linux-gnu (x86_64) using  EditLine wrapper

[email protected] 03:13:15> create table test(id int,name varchar(20),name2 varchar(20),d datetime,primary key(id)) engine=innodb;

Query OK, 0 rows affected (0.00 sec)

[email protected] 03:48:04>insert into test values(1,’xc’,’sds’,now()),(2,’xcx’,’dd’,now()),(3,’sdds’,’ddd’,now()),(4,’sdsdf’,’dsd’,now()),(5,’sdsdaa’,’sds’,now());

Query OK, 5 rows affected (0.00 sec)

Records: 5  Duplicates: 0  Warnings: 0

[email protected] 03:48:05>insert into test values(6,’xce’,’sdsd’,now()),(7,’xcx’,’sdsd’,now()),(8,’sdds’,’sds’,now()),(9,’sdsdsdf’,’sdsdsd’,now()),(10,’sdssdfdaa’,’sdsdsd’,now());

Query OK, 5 rows affected (0.01 sec)

Records: 5  Duplicates: 0  Warnings: 0

建立索引ind_1：

[email protected] 03:13:57>alter table test add index ind_1(name,d);

Query OK, 0 rows affected (0.01 sec)

Records: 0  Duplicates: 0  Warnings: 0

[email protected] 03:15:55>explain select count(*) from test;

+—-+————-+——-+——-+—————+——-+———+——+——+————-+

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

+—-+————-+——-+——-+—————+——-+———+——+——+————-+

|  1 | SIMPLE      | test  | index | NULL          | ind_1 | 52      | NULL |   10 | Using index |

+—-+————-+——-+——-+—————+——-+———+——+——+————-+

[email protected] 08:01:56>alter table test add index ind_2(d);

Query OK, 0 rows affected (0.03 sec)

Records: 0  Duplicates: 0  Warnings: 0

新增ind_2：

[email protected] 08:02:09>explain select count(*) from test;

+—-+————-+——-+——-+—————+——-+———+——+——+————-+

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

+—-+————-+——-+——-+—————+——-+———+——+——+————-+

|  1 | SIMPLE      | test  | index | NULL          | ind_2 | 9       | NULL |   10 | Using index |

+—-+————-+——-+——-+—————+——-+———+——+——+————-+

1 row in set (0.00 sec)

版本【5.1.48】中首先明智的選擇ind_1來完成掃描，並沒有考慮到使用主鍵（全索引掃描）來完成查詢，隨後新增ind_2，由於 ind_1的key長度是大於ind_2 key長度，所以mysql選擇更優的ind_2來完成查詢，可以看到mysql在選擇方式上也在慢慢智慧了。

觀察效能：

5.1.48

[email protected] 08:49:32>set profiling =1;

Query OK, 0 rows affected (0.00 sec)

[email protected] 08:49:41>select count(*) from test;

+———-+

| count(*) |

+———-+

|  5242880 |

+———-+

1 row in set (1.18 sec)

[email protected] 08:56:30>show profile cpu,block io for query 1;

+——————————–+———-+———-+————+————–+—————+

| Status                         | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |

+——————————–+———-+———-+————+————–+—————+

| starting                       | 0.000035 | 0.000000 |   0.000000 |            0 |             0 |

| checking query cache for query | 0.000051 | 0.000000 |   0.000000 |            0 |             0 |

| Opening tables                 | 0.000014 | 0.000000 |   0.000000 |            0 |             0 |

| System lock                    | 0.000005 | 0.000000 |   0.000000 |            0 |             0 |

| Table lock                     | 0.000010 | 0.000000 |   0.000000 |            0 |             0 |

| init                           | 0.000015 | 0.000000 |   0.000000 |            0 |             0 |

| optimizing                     | 0.000007 | 0.000000 |   0.000000 |            0 |             0 |

| statistics                     | 0.000015 | 0.000000 |   0.000000 |            0 |             0 |

| preparing                      | 0.000012 | 0.000000 |   0.000000 |            0 |             0 |

| executing                      | 0.000007 | 0.000000 |   0.000000 |            0 |             0 |

| Sending data                   | 1.178452 | 1.177821 |   0.000000 |            0 |             0 |

| end                            | 0.000016 | 0.000000 |   0.000000 |            0 |             0 |

| query end                      | 0.000005 | 0.000000 |   0.000000 |            0 |             0 |

| freeing items                  | 0.000040 | 0.000000 |   0.000000 |            0 |             0 |

| logging slow query             | 0.000002 | 0.000000 |   0.000000 |            0 |             0 |

| logging slow query             | 0.000086 | 0.000000 |   0.000000 |            0 |             0 |

| cleaning up                    | 0.000006 | 0.000000 |   0.000000 |            0 |             0 |

+——————————–+———-+———-+————+————–+—————+

對比效能：

5.1.45

[email protected] 08:57:18>set profiling =1;

Query OK, 0 rows affected (0.00 sec)

[email protected] 08:57:21>select count(*) from test;

+———-+

| count(*) |

+———-+

|  5242880 |

+———-+

1 row in set (1.30 sec)

[email protected] 08:57:27>show profile cpu,block io for query 1;

+——————————–+———-+———-+————+————–+—————+

| Status                         | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |

+——————————–+———-+———-+————+————–+—————+

| starting                       | 0.000026 | 0.000000 |   0.000000 |            0 |             0 |

| checking query cache for query | 0.000041 | 0.000000 |   0.000000 |            0 |             0 |

| Opening tables                 | 0.000014 | 0.000000 |   0.000000 |            0 |             0 |

| System lock                    | 0.000005 | 0.000000 |   0.000000 |            0 |             0 |

| Table lock                     | 0.000008 | 0.000000 |   0.000000 |            0 |             0 |

| init                           | 0.000015 | 0.000000 |   0.000000 |            0 |             0 |

| optimizing                     | 0.000006 | 0.000000 |   0.000000 |            0 |             0 |

| statistics                     | 0.000014 | 0.000000 |   0.000000 |            0 |             0 |

| preparing                      | 0.000012 | 0.000000 |   0.000000 |            0 |             0 |

| executing                      | 0.000007 | 0.000000 |   0.000000 |            0 |             0 |

| Sending data                   | 1.294178 | 1.293803 |   0.000000 |            0 |             0 |

| end                            | 0.000016 | 0.000000 |   0.000000 |            0 |             0 |

| query end                      | 0.000004 | 0.000000 |   0.000000 |            0 |             0 |

| freeing items                  | 0.000040 | 0.000000 |   0.001000 |            0 |             0 |

| logging slow query             | 0.000002 | 0.000000 |   0.000000 |            0 |             0 |

| logging slow query             | 0.000080 | 0.000000 |   0.000000 |            0 |             0 |

| cleaning up                    | 0.000006 | 0.000000 |   0.000000 |            0 |             0 |

+——————————–+———-+———-+————+————–+—————+

從上面的profile中可以看到在Sending data上，差異還是比較明顯的，mysql不需要掃描整個表的頁塊，而是掃描表中索引key最短的索引頁塊來完成查詢，這樣就減少了很多不必要的資料。

PS:innodb是事務引擎，所以在葉子節點中除了儲存本行記錄外，還會多記錄一些關於事務的資訊（DB_TRX_ID ,DB_ROLL_PTR 等)，因此單行長度額外開銷20個位元組左右，最直觀的方法是將myisam轉為innodb，儲存空間會明顯上升。那麼在主表為t(id,name,pk(id)),二級索引ind_name(name,id),這個時候很容易混淆，即使只有兩個欄位，第一索引還是比第二索引要大（可以通過innodb_table_monitor觀察表的的內部結構）在查詢所有id的時候,優化器還是會選擇第二索引ind_name。

相關推薦

讓天下沒有難用的資料庫 » Mysql中對primary key一點選擇改變

在5.1.46中優化器在對primary key的選擇上做了一點改動： Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the fu

讓天下沒有難用的資料庫 » Mysql 中int[M]

我們在定義數字型別的資料型別的時候，往往考慮該數字型別的資料能否裝的下該欄位的最大值，如狀態位的欄位：tinyint，表的主鍵：int，或者bigint，今天在看到開發同學提交表結構設計文件中看到數值型別的欄位定義為int(255)，int(20),int(2)當時一下還沒有反映過來，我們知道在my

讓天下沒有難用的資料庫 » 生產庫中遇到mysql的子查詢

使用過oracle或者其他關係資料庫的DBA或者開發人員都有這樣的經驗，在子查詢上都認為資料庫已經做過優化，能夠很好的選擇驅動表執行，然後在把該經驗移植到mysql資料庫上，但是不幸的是，mysql在子查詢的處理上有可能會讓你大失所望，在我們的生產系統上就由於碰到了這個問題： select  i_i

讓天下沒有難用的資料庫 » mysql中的Waiting for tables

接著上篇中遇到的mysql子查詢，在問題的診斷中，丹臣注意到一個較為嚴重的問題，就是我們生產庫中全部的資料庫訪問請求都處於Waiting for tables的狀態，在將大查詢kill掉後，所有的請求恢復正常；簡單的理解為大查詢阻塞了其他訪問請求，但是這個理論是不可信，如果阻塞該表的DML還可以理解

讓天下沒有難用的資料庫 » mysql explain 中key_len的計算

今天丁原問我mysql執行計劃中的key_len是怎麼計算得到的，當時還沒有注意，在高效能的那本書講到過這個值的計算，但是自己看執行計劃的時候一直都沒有太在意這個值，更不用說深討這個值的計算了： ken_len表示索引使用的位元組數，根據這個值，就可以判斷索引使用情況，特別是在組合索引的時候，判斷所

讓天下沒有難用的資料庫 » MySQL 5.5版本注意大記憶體導致DDL變慢的問題

最近在協助使用者進行系統重構，RDS測試選型自然成為了本專案的一個重點，但是使用者在測試不同規格的時候發現大規格的例項效能居然不如小規格，4C32G規格效能比8C64G規格高出10%，其效能監控也是非常的正常，4C32G規格是8C64G規格資源消耗的一半，TPS也是相當，那問題到底出現在那裡？ CP

讓天下沒有難用的資料庫 » MySQL鎖問題最佳實踐

最近一段時間處理了較多鎖的問題，包括鎖等待導致業務連線堆積或超時，死鎖導致業務失敗等，這類問題對業務可能會造成嚴重的影響，沒有處理經驗的使用者往往無從下手。下面將從整個資料庫設計，開發，運維階段介紹如何避免鎖問題的發生，提供一些最佳實踐供RDS的使用者參考。 一．設計階段：在資料庫設計階段，引擎選擇

讓天下沒有難用的資料庫 » RDS MySQL空間優化最佳實踐

在前三期介紹了RDS for MySQL引數優化，鎖問題以及延遲優化最佳實踐之後，本期將介紹儲存空間相關的最佳實踐。 儲存空間是RDS很重要的一個指標，在RDS的工單問題中，空間問題的諮詢可以排在top 5，當RDS的實際使用空間超過了購買的空間後，例項就會被鎖定了，這樣就會導致應用無法再寫入，更新

讓天下沒有難用的資料庫 » MySQL update use index merge(Using intersect) increase chances for deadlock

昨天一同事發現線上系統在併發更新的時候出現了死鎖，通過排查定位於update更新使用了兩個索引導致，死鎖資訊如下： *** (1) TRANSACTION: TRANSACTION 29285454235, ACTIVE 0.001 sec fetching rows mysql tables in

讓天下沒有難用的資料庫 » RDS MySQL引數調優最佳實踐

前言 很多時候，RDS使用者經常會問如何調優RDS MySQL的引數，為了回答這個問題，寫一篇blog來進行解釋： 哪一些引數不能修改，那一些引數可以修改； 這些提供修改的引數是不是已經是最佳設定，如何才能利用好這些引數； 哪些引數可以改 細心的使用者在購買RDS的時候都會看到，不同規格能夠提供

讓天下沒有難用的資料庫 » mysql主鍵的缺少導致備庫hang

最近線上頻繁的出現slave延時的情況，經排查發現為使用者在刪除資料的時候，由於表主鍵的主鍵的缺少，同時刪除條件沒有索引，或或者刪除的條件過濾性極差，導致slave出現hang住，嚴重的影響了生產環境的穩定性，也希望通過這篇部落格，來加深主鍵在innodb引擎中的重要性，希望使用者在使用RD

讓天下沒有難用的資料庫 » mysql的資料恢復

資料庫資料被誤刪除是經常看到的事情，資料的恢復也就自然成為了DBA很重要的一門基本功夫，比較笨拙的辦法是拉出歷史的備份到另外的一臺機器恢復出來，但是這種方法如果資料量比較大的話，往往會耗費較長的時間，以前在使用oracle的時候，提供了很多資料恢復的辦法，常用的辦法就是採用閃回flashback，或

讓天下沒有難用的資料庫 » mysql sql優化之straight_join

在oracle中可以指定的表連線的hint有很多：ordered hint 指示oracle按照from關鍵字後的表順序來進行連線；leading hint 指示查詢優化器使用指定的表作為連線的首表，即驅動表；use_nl hint指示查詢優化器使用nested loops方式連線指定表和其他行源，

讓天下沒有難用的資料庫 » MySql sql優化之order by desc/asc limit M

Order by desc/asc limit M是我在mysql sql優化中經常遇到的一種場景，其優化原理也非常的簡單，就是利用索引的有序性，優化器沿著索引的順序掃描，在掃描到符合條件的M行資料後，停止掃描；看起來非常的簡單，但是我經常看到很多效能較差的sql沒有利用這個優化規律，下面將結合一些

讓天下沒有難用的資料庫 » 淺談mysql的子查詢

mysql的子查詢的優化一直不是很友好，一直有受業界批評比較多,也是我在sql優化中遇到過最多的問題之一，你可以點選這裡 ，這裡來獲得一些資訊，mysql在處理子查詢的時候，會將子查詢改寫,通常情況下，我們希望由內到外，也就是先完成子查詢的結果，然後在用子查詢來驅動外查詢的表，完成查詢，但是恰恰相反

讓天下沒有難用的資料庫 » open/close table on mysql

我們知道mysql是一個支援多執行緒的資料庫，尤其在innodb儲存引擎出現後，對mysql的事務，併發，鎖支援得到了極大提高。在高併發的訪問的應用場景中，應用端大量併發的程序發問資料庫，而資料庫中的資料表在磁碟上以資料檔案存放，在unix，linux的系統呼叫中，是依賴於檔案描述符的。不同的os對

讓天下沒有難用的資料庫 » mysql給同一個表新增多個索引的測試

分別給xc表新增ind_name和ind_status的索引： [email protected] 11:44:13>create index ind_name on xc(name); Query OK, 6815744 rows affected (1 min 43.75 sec

讓天下沒有難用的資料庫 » RDS MySql支援online ddl

在日常和客戶溝通的過程中發現，他們在做mysql ddl變更的時候由於MySql本身的缺陷不支援online ddl，導致他們的業務不得不hang住一會兒，表越大，時間影響越長，所以期待有更好的解決方法；有些使用者也想了一些方法，比如通過主備切換的方法，先在備庫進行ddl，然後在通過主備切換到原主庫

讓天下沒有難用的資料庫 » 查詢表中最新紀錄

    今天開發給了一條sql，查詢表中最近更新的一條記錄：        select id,        type,        object_id,        nick,        isv_id,        next_auditor_role,        status,  

讓天下沒有難用的資料庫 » 檢視mysql實時執行sql的工具

該工具為我的同事朱旭開發的一款可以檢視mysql資料庫實時執行的sql狀況的工具，以前苦於通過show processlist/show full processlist抓取sql的同志們現在只要盯一盯螢幕就可以了，非常的方便，點選這裡進行下載,使用方法也很簡單，如下： [email pr