背景
基於某些業務開發過程中，會遇到這樣的查詢語句：select * from table where id in(1, 2, 3)， 但是當in裡面的資料量非常大的時候，有些資料庫會對in 的資料量有大小限制，比如oracel大小限制是1000，因此如果能有一種替代in 大量資料，並且效能還不錯的方案就好了。
實戰1、使用in方案查詢結果，查詢時間為：0.078s，總資料量60多萬。
select * from designmaterial ds where ds.materialid in(
「00010448」,
「00010450」,
「00010454」,
「00010455」,
「00010457」,
「00010460」,
「00010466」,
「00010470」,
「00010474」,
「00010475」,
「00010477」,
「00010484」,
「00010487」,
「00010489」,
「00010491」,
「00010492」,
「00010493」,
「00011018」,
「00011019」,
「00011020」,
「00011071」,
「00011072」,
「00011073」)
2、改用替代方案，查詢時間為：0.053s左右，總資料量60多萬
select *
from (
select 「00010448」 cid union all
select 「00010450」 union all
select 「00010454」 union all
select 「00010455」 union all
select 「00010457」 union all
select 「00010460」 union all
select 「00010466」 union all
select 「00010470」 union all
select 「00010474」 union all
select 「00010475」 union all
select 「00010477」 union all
select 「00010484」 union all
select 「00010487」 union all
select 「00010489」 union all
select 「00010491」 union all
select 「00010492」 union all
select 「00010493」 union all
select 「00011018」 union all
select 「00011019」 union all
select 「00011020」 union all
select 「00011071」 union all
select 「00011072」 union all
select 「00011073」
) as tmp,designmaterial t
where tmp.cid = t.materialid;
總結經過mysql資料庫大量測試結果替代方案比in語句快了不少，特別是資料量比較大的時候，所以以後如果遇到in查詢過程可以使用該替代方案。
記一次除錯
這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊，本來和老婆說好準時下班回家吃飯的，結果被這個問題拖了老久。這是乙個gradle的plugin，用來resolve公司內部的dependency的，弄完了跑測試專案的，拋乙個npe，而且npe還不在自己的 裡面。...
記一次 EqualsAndHashCode的疑惑
lombok的使用真的是讓開發人員欲罷不能，乙個 data不管有多少屬性全部搞定，以後加字段也不用從新生成get和set方法。不過這裡還是有乙個小坑需要注意一下，舉個例子 public class equalsandhashcodetest data noargsconstructor access...
記一次除錯
這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊，本來和老婆說好準時下班回家吃飯的，結果被這個問題拖了老久。這是乙個gradle的plugin，用來resolve公司內部的dependency的，弄完了跑測試專案的，拋乙個npe，而且npe還不在自己的 裡面。...