對於一些敏感資料，往往會對其加密後再入庫，這個是對資料安全性的乙個最為簡單的措施。
最常見的莫過於手機號碼和身份證號了，相信還是有不少公司對這些敏感資訊是明文儲存的。
萬一被別人發現系統漏洞，或者是被拖庫，那基本上就涼涼了。
老黃最近也是發現了公司內部乙個系統有這樣的問題，剛發現的時候都嚇了我一跳，這麼赤裸裸的明文手機號和身份證號。
第一反應就是要把這兩個資料進行加密處理。
既然要加密處理，那麼正在使用的系統肯定就會受到影響，而且幾千萬資料，也不是幾分鐘就能搞定的。
這個系統用的資料庫是阿里雲的rds(sql server)。
下面簡單說一下老黃這邊的處理方案。
整個處理的流程是分了三個步驟：
修改資料庫中的字段長度
系統要更新乙個版本做相容處理，寫入要用統一的加密方法，讀取的時候，要加乙個長度判斷，當長度大於20的時候，需要進行解密操作，這樣才能確保不會把密文直接展示出去。
修改資料
之前資料庫給這兩個字段設定的長度都是20，現在統一調整成150。
公司內部已經統一了一套加解密方法了，所以系統調整這一塊是比較簡單的，統一在資料層處理。
剩下的就是去資料庫改資料了。
統一的加密方法，在資料庫中沒有辦法直接使用，所以只能單獨寫個程式去處理。
改資料也細分為下面3步。
讀取源資料，加密相關字段
將加密的資料寫入到一張臨時表中
根據臨時表去更新源表的相關字段
這裡的最為核心的乙個就是批量寫入和批量更新。如果一條條更新，那不知道要等多久才能全部處理完。
先是寫乙個控制台程式，根據id分批次，把加密好的資料，以五千條一次寫入的頻率，一百萬資料當成乙個批次。
var flag = true;
var begin = 0;
var tmpend = begin + 5000;
var end = 1000000;
while (flag)
using (sqlconnection conn = new sqlconnection(connstr))
begin = tmpend;
tmpend += 5000;
if (tmpend >= end || list == null || !list.any())
console.writeline(begin);
}
為保證寫入的速度，先不要在那個臨時表建索引，等資料寫進去後再給id建索引。把資料寫進臨時表後，下面就是直接用sql指令碼來批量更新了。
-- 建索引
create index idx_enc_tmp_id on enc_tmp (id)
-- 批量更新
update dbo.yourtable
set phoneno= a.phoneno, idcard = a.idcard
from dbo.yourtable b
inner join dbo.enc_tmp a
on a.id=b.id
-- 這裡更新要看資料庫的配置，如果配置高，可以一次更新，不然就建議25萬或50萬乙個批次
-- where a.id >= 0 and a.id <= 500000
-- 查詢校驗一下
select top 100 [id]
,[idcard]
,[phoneno]
from dbo.yourtable with (nolock)
where id > 0 and id <= 500000
order by id asc
-- 清除臨時表的資料
truncate table dbo.enc_tmp
-- 刪除索引
drop index idx_enc_tmp_id on enc_tmp
修改資料的過程中，也涉及到了兩個知識點，資料的批量插入和批量更新。
批量更新資料
update bs storage setstoreqty storeqty a.mqty from select nb disbill.companyid,goodsid,nb disbill.outstoreid,outstorepos,mqty,nb disbill.billno from n...
記一次使用原生jdbc批量插入資料時踩到的坑
有一業務場景,需要初始化所有員工本月的考勤台賬.基本流程是刪掉原來的資料 然後重新插入 插入月統計表資料 當時場景900員工,乙個月算30天,一次初始化要插入2.7w資料.如果dao層框架insert.要差不多40s.所以用jdbc進行批量操作 public void initmonth ps.ex...
oracle批量更新資料
目的 兩個表t1,t2，t1裡面的字段，id，name，t2也是，將t2表和t1表裡面相等的id的記錄的name欄位更新到t1表裡面 1 update t1 set name select t2.name from t2 where t2.id t1.id where exits select 1 ...