mysql聯合索引最左匹配原因？

最左側前綴匹配原則

mysql建立聯邦索引時，會遵循最左前綴匹配的原則，即最左優先級，檢索數據時從聯邦索引的最左邊匹配。

示例:

為列Gid、列Cid和列Sid建立聯合索引。

聯合索引uni_Gid_Cid_SId實際上建立了三個索引:(Gid)，(Gid，Cid)和(Gid，Cid，SId)。

插入模擬數據

查詢實例:

上面的查詢語句將按照最左前綴匹配原則執行，檢索時將使用索引(Gid，Cid)進行數據匹配。

注意

索引的字段可以按任何順序排列，例如:

兩個查詢語句中都使用了Index(Gid，Cid)。mysql創建聯合索引的規則是對聯合索引最左邊的數據，也就是第一個字段Gid進行排序，然后在第一個字段排序的基礎上對第二個字段Cid進行排序。實際上，它相當于實現了一個類似orderbyGidCid的排序規則。

可能有人會奇怪，第二條查詢語句和最左邊的前綴不匹配:首先，可以肯定的是，兩條查詢語句都保證了索引中的Gid和Cid字段(Gid，Cid)，只是順序不同，查詢條件相同，最終查詢結果肯定相同。既然結果一樣，那么哪個順序是最好的呢？此時，我們可以使用mysql查詢優化器

如何使用使用分頁查詢來適應挖掘海量數據呢？

在數據挖掘的各種算法中，經常需要遍歷整個數據庫(表)。在現實中，數據庫可能非常大，用簡單的Select*方法往往無法遍歷和提取數據表中的所有元組。直接使用Select*有兩大問題。一個是在Select*之后，數據庫提交所有信息可能需要很長時間。另一個是結果可能非常大，遠遠超過內存限制。

現在各種主流數據庫都支持分頁查詢。

以Oracl:。

從XX中選擇*.表1，其中第50行

以MySQL為例，提供了limit關鍵字，更容易獲取中間某個區間的行數據。

例如，:從表1中選擇*限制50，100。MySQL的limit關鍵字比Oracle的更方便使用。然而，我還沒有t研究了各個數據庫的分頁查詢速度。聽一些專家說Oracle提供的分頁查詢效率更高。

Hibernate等數據持久層提供的分頁查詢可以屏蔽不同數據庫之間具體SQL實現的差異。

像Hiberante這樣的數據持久層工具的一個好處就是可以篩選出不同數據庫之間的一些細節差異。

分頁查詢的SQL在不同的數據庫中是不一樣的，最好用Hibernate之類的工具來統一。

查詢q會話.創建查詢(