mycat+mysql實現分庫分表；功能需要遍歷表，資料量有點大，於是通過id排序分頁查詢。
在實現過程中發現有部分id查不出來，功能排期只能被迫延後。
在確認了**和sql語句沒有問題後，目光轉至mycat與mysql排序邏輯上來。
確認了mycat與mysql排序邏輯有問題，至少mycat與mysql排序邏輯表現不一致。
1.執行以下語句
select id from 《表名》 where id='aaabaorw/0rolrp3fozozirplm1qvqtq';2.執行以下語句
select id from 《表名》 where id>='aaabaorw/0rolrp3fozozirplm1qvqtq' order by id asc limit 10;mycat聚合排序原理
mycat執行select * from 《表名》 where id>='aaabaorw/0rolrp3fozozirplm1qvqtq' order by id asc limit 10時，會在全部mysql分庫中，執行上述語句，然後在mycat中對所有mysql分庫的結果重新排序，拿出10條。
然後去找mycat原始碼（1.6版本），找到了這個類rowdatapacketsorter，發現該類最後排序大小比較是採用bytestools.compareto方法，位元組排序，那應該是大小寫敏感的。於是想，mysql中排序是不是大小不敏感？
看mysql的字元排序
檢視使用表的排序規則，發現是utf8mb4_general_ci，然後在去搜尋一波這個排序規則發現
字尾 ci :不區分大小寫
bin ：區分大小寫
果不其然，我使用的mysql規則是大小不敏感的。
至此問題找到，於是分頁不採用以uuid排序，而是使用了另乙個全部大寫的字段，問題也得以解決。
在使用mycat+mysql字元排序時要注意大小寫是否敏感的問題。
之前網上搜尋看到mycat聚合排序有bug，還以為被自己撞見了，原來發現非也、非也！
一次GC問題定位
同事有段 執行時間過長，需要進行優化,hashmultimapmap for 400w 96 剛開始以為是計算過程docompute效率低造成的，所以想各種方法優化計算，提前計算 多執行緒 等等等等，最終如下 多執行緒計算 計算結果放入佇列 concurrentlinkedqueue queue q...
沒有pdb也要定位問題 一次注入崩潰的定位過程
最近遇到乙個注入過程中崩潰的問題，花了比較長的時間定位，寫下來記錄一下 一 背景 我寫了乙個程序s，s程序會執行時會監控程序中是否有i程序在執行，如果i程序運動的話，s程序就注入乙個my.dll到i程序中，並在i程序中執行乙個myfunc的函式 如下圖 我寫完程式後，執行測試，功能是沒有錯誤的，一切...
記一次mysql不走索引的問題定位
問題 sql為三表關聯，關聯的字段上都加上了唯一索引，查詢時卻不走索引導致sql執行超時。檢視explain都走的all全表掃瞄。基於上述定位 為什麼沒走索引呢？進行多表關聯查詢時，要滿足 1 表關聯使用的條件欄位中字段的長度是否是一致的 2 兩表關聯使用的條件欄位中字段的編碼是否是一致的 以上兩個...