MySQL的前綴索引和覆蓋指數（全索引）

Question

當我用mysql-5.7.17，我發現了什麼。 我使用Innodb和charst：utf8。

覆蓋索引表模式：

CREATE TABLE test_table ( c_pk varchar(20) NOT NULL DEFAULT '', c_default varchar(32) DEFAULT NULL, c_notnull varchar(20) NOT NULL, PRIMARY KEY (c_pk), KEY IDX_test_table (c_notnull) ) ENGINE=InnoDB DEFAULT CHARSET=utf8

前綴索引表模式：

CREATE TABLE ntable ( c_pk varchar(20) NOT NULL DEFAULT '', c_default varchar(32) DEFAULT NULL, c_notnull varchar(20) NOT NULL, PRIMARY KEY (c_pk(10)), KEY IDX_test_table (c_notnull(10)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8

並插入相同數據於ntable和TEST_TABLE （數據具有數目和多字節字符： EX - 123，한글） 當我執行select查詢，如：SELECT * FROM ntable WHERE c_notnull LIKE「윤선중윤선중 선중윤선중윤선중윤선중％';

表結果的差異。 選擇數據相同，但順序不同。

原來MySQL的前綴索引和覆蓋指數（全指數）的結果是不同的？

Answer 1

如果沒有ORDER BY，引擎是免費的在它選擇的任何順序提供行。要發現什麼樣的順序結果將可能是，我們需要深入實施：自PRIMARY KEY

在第一種情況下KEY IDX_test_table (c_notnull)是B樹第一下令c_notnull，然後通過c_pk被隱式追加到每一個次級鍵。

在第二種情況下，索引實際上是(LEFT(c_notnull, 10), c_pk)。第十個之後的字符不參與訂單。

嘗試這些，看看我的分析是正確的：

SELECT ... ORDER BY c_notnull, c_pk;   -- expect it to match case 1 
SELECT ... ORDER BY LEFT(c_notnull, 10), c_pk; -- expect it to match case 2 

這是一個「前綴」指數非常罕見的是有用的。我建議你避免它，除非c_notnull過長（如TEXT），以允許完整的索引。

當訂單很重要時，請使用ORDER BY。