摘要

最近遇到一個慢sql，在排查過程中發現和分庫分表后的索引設置有關系，總結了下問題。

問題

在進行應用健康度盤點時，發現有個慢sql

如下

select brandgoodid from brandgood_0020

where userid = xxx AND

brandgoodid in("xxx1","xxx2")

表結構,按照userid進行的分表。

CREATE TABLE`brandgood_0020` (

`brandgoodid` char(30) NOT NULL COMMENT ,

`user_id` int(10) unsigned DEFAULT NULL COMMENT '用戶id',

`created` timestamp NULL DEFAULT CURRENT_TIMESTAMP,

`last_modified` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

`deleted` bit(1) NOT NULL DEFAULT b'0',

PRIMARY KEY (`brandgoodid`),

KEY `idx_userid` (`userid`) USING BTREE,

) ENGINE=InnoDB DEFAULT CHARSET=utf8

explain一下發現走的是userid這個索引，一個用戶下面有很多商品，也就有了很多brandgoodid，所以有可能會很慢，因為要掃描很多的索引鍵去過濾brandgoodid值。

而寫這個SQL的人期望走的主鍵索引，而不是'userid'的索引。因為用主鍵索引，就是N次主鍵掃描(N表示in中的數量)。

分析

直接原因很明顯

IN 這個查詢誤導了mysql的優化器，選錯了索引

IN 查詢常常會影響mysql server的判斷。主要是IN里面的值數量不同，會影響掃描行數的不同，所以常常會出現索引選擇不一致。之前也總結過一篇SQL IN 一定走索引嗎

解決

因為用戶查詢的brandgoodlid是限定在某個group維度下的，一個group對應的brandgood是有限的，在這個業務中，通常小于10。所以這個地方使用主鍵索引，效率更高。解決方法也就是這地方需要force index強制走PRIMARY index。

擴展

分庫分表后的索引

為什么題目叫分庫分表后的索引問題的，直接原因和分庫分表并沒有什么關系啊？

因為在排查問題時，犯了一個錯誤。以為路由到具體的brandgood_0020表后，可以直接根據brandgoodid主鍵索引來查詢了。認為和一些分布式數據庫(cassandra)一樣,是clustering key+partition key這種索引數據?？梢愿鶕lustering key到數據的節點的partition塊，然后根據local index 找到對應的數據。

但其實mysql的分庫分表不一樣，分表鍵不是索引，只是客戶端路由。只負責找到對應的表。到表以后，就是和單表一樣查詢邏輯。

因為分表鍵不是索引，但是查詢語句是必須要帶著分表鍵，那意味著我們的分庫分表以后的表索引大部分要建成聯合索引了，分表鍵+索引鍵。

要不然我們的查詢語句 select xx from table where 分表鍵=xxx AND a =xxx，是走不了聯合索引的。只能走單索引。單索引mysql server要面臨著索引選擇的問題。

當然并不是絕對的，比如上面我舉的那個案例。按照這個思路查看了下其他的分表索引。果然表上的大部分索引都是非聯合索引，還是直接從單表copy過來的索引。這些索引基本上都是無用的，因為都的是userid索引.

索引選擇的問題

我們這個案例是因為判斷掃描行數的時候出問題了。

總結

以上是生活随笔為你收集整理的mysql分表后怎么索引_分库分表后的索引问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。