一、介紹

公司最近在搞服務分離，數據切分的工作，因為訂單和訂單項表的數據量實在過大，而且每天都是以50萬的數據量在增長，基于現狀，項目組決定采用分庫的方式來解決當前遇到的問題。

那具體怎么切分呢？

分庫的策略其實還比較簡單，主要是要確定分片的字段和策略。

最開始是想通過主鍵ID的奇、偶數來分兩個庫，order_1庫主要用于存儲奇數的ID，order_2庫主要用于存儲偶數的ID。

但是這種切分，局限性非常大，因為最多只能分兩個庫，如果隨著數據量的增大，后面就沒很難在分了。

之后又想到了另一個分片字段：城市ID，因為訂單表上有城市ID的屬性，我們可以基于此進行分庫，但是全國有幾百個城市，不可能分幾百個庫或者表，最后的討論結果是：

• 城市ID的生成固定大小，默認三位數，100～999
• 將訂單表分成三個庫，order_1、order_2、order_3
• 當城市ID 在100~399區間，就存儲到order_1庫
• 當城市ID 在400~699區間，就存儲到order_2庫
• 當城市ID 在700～999區間，就存儲到order_3庫

通過城市ID進行分片，如果后期訂單數據量進一步過大，也可以進一步的分庫！

基于Mysql數據庫，使用最廣、最成熟的分布式中間件當屬于Mycat。

但是，自從采用Mycat中間件進行分庫之后，發現了非常多的坑，下面我們就一起來看看這些坑點！

二、細數Mycat中的坑點

1. 分頁查詢會出現全表掃描

當我們把功能上線之后，測試人員在頁面上從末尾頁不停的往前分頁查詢訂單數據的時候，運維平臺突然報監控到很多慢 SQL 報警。

以下是運維平臺監控到的慢sql語句：

SELECT id FROM order
WHERE OrderCreateTime BETWEEN '2021-05-01 00:00:00' AND '2021-06-01 00:00:00'
ORDER BY id DESC
LIMIT 0, 151400

于是，運維同學開始找到我們，說我們程序有問題，并在群里開始吐槽我們開發寫的啥玩意，但是我們開發堅信程序沒有問題，通過查詢日志，我們排查到代碼的查詢語句是長這樣的：

SELECT id FROM order
WHERE OrderCreateTime BETWEEN '2021-05-01 00:00:00' AND '2021-06-01 00:00:00'
ORDER BY id DESC
LIMIT 151300, 100

與實際運維給的慢sql語句中的LIMIT 0, 151400完全不符合。

包括我們自己也 review 了代碼，把 sql日志也截了圖，找技術總監說理去。

之后，當測試人員再次點擊分頁查詢的時候，運維又監控到了LIMIT 0, 151400這種怪異的SQL，我們花了好幾個小時排查，在本地跑測試，還是沒發現什么問題，真的感覺到了要懷疑人生了！

當多次測試的時候，這個問題每次都能復現，讓我想起了一個問題，是不是 Mycat 分頁的時候，對全表掃描了。

后來經過查閱資料，才發現真有這個坑！

在分庫分表的情況下，宕 limit 的開始位置特別大的時候，例如大于某表的總行數時，mycat 將查詢各個分表的結果集返，然后在mycat中進行合并和排序，再返回結果。

例如，當你原始的 sql 語句是這樣的：

SELECT * FROM table_name WHERE type='xxx' ORDER BY create_time LIMIT 10000,1000

通過 mycat 執行的結果，會是這樣的：

SELECT * FROM table_name WHERE type='xxx' ORDER BY create_time LIMIT 0,11000

結果集特別大的情況會導致查詢很慢，嚴重的情況會直接導致 mycat OOM！

因此，在分庫分表的情況，不要用 mycat 進行大批量的數據分頁查詢，通過條件過濾，減小分頁的數據量大小!

2. 子查詢結果偶爾不完整

當通過某些條件，篩選訂單項數據時，測試人員反饋某些數據偶爾出現不完整。

具體SQL操作如下：

select id,productName
from orderItem
where orderId in (
 select id from order where userName = '張三'
)

預期的查詢結果時：

1,"巧克力"
2,"可樂"
3,"果凍"
4,"蘋果手機"

但是實際查詢的時候，有時候的結果如下：

1,"巧克力"
2,"可樂"
4,"蘋果手機"

在網上查詢了相關的問題，在分庫分表的情況下，子查詢出了偶爾查詢不到完整數據外，還會出現 mycat 內部死鎖，因此盡量在代碼中不要使用子查詢，而是采用主鍵ID或是索引字段進行單表查詢，這樣效率會大大提升！

3. 跨分片join問題

由于歷史代碼的緣故，訂單服務里面存在很多各種連表操作，例如：

select a.*,b.accountName,c.address
from order a
left join account b on a.accountId = b.id
left join account_address c on  b.id = c.accountId
where a.orderId = 11110011

但是在走 mycat 查詢之后，直接報錯！

原因是：mycat 目前只支持兩張分片表的 Join，如果要支持多張表需要自己改造程序代碼或者改造Mycat的源代碼。

4. 部分SQL語法不支持

在實際使用的時候，發現還有部分sql語句是不支持的。

復制插入(不支持)

insert into......select.....

復雜更新(不支持)

update a, b set a.remark='備注' where a.id=b.id;

復雜刪除(不支持)

delete a from a join b on a.id=b.id;

還有就是不支持跨庫連表操作！

5. 不支持存儲過程創建和調用

有一點，需要大家注意的，在走 mycat 中間件的方式與數據庫連接的時候，如果代碼中寫了存儲過程等語句，是 mycat 是不支持調用的，因此盡量不要使用!

三、小結

雖然咱們介紹了 mycat 有一些坑，但是這些坑，通過一些優化手段還是可以避免的。

實際上，mycat 作為分庫分表的中間件，也有許多的優勢，例如下面官網的介紹。

據了解，mycat 是目前最成熟、使用最廣的中間件，因此大家在使用的時候，不需要帶有啥顧慮，對于以上的坑點，盡可能的避免。