使用工具pt-archiver
原理解析
作為MySQL DBA，可以說應該沒有不知道pt-archiver了，作為pt-toolkit套件中的重要成員，往往能夠輕松幫助DBA解決數據歸檔的問題。例如線上一個流水表，業務僅僅只需要存放最近3個月的流水數據，三個月前的數據做歸檔即可，那麼pt-archiver就可以輕松幫你完成這件事情，甚至你可以配置成自動任務，無需人工干預。
作為DBA，我們應該知其然更應該知其所以然，這樣我們也能夠放心地使用pt工具。相信很多DBA都研究過pt-online-schema-change的原理，那麼今天我們深入刨一刨pt-archiver的工作原理。
一、原理觀察
土人有土辦法，我們直接開啟general log來觀察pt-archiver是如何完成歸檔的。
命令
pt-archiver --source h=127.0.0.1,u=xucl,p=xuclxucl,P=3306,D=xucl,t=t1 --dest h=127.0.0.1,P=3306,u=xucl,p=xuclxucl,D=xucl_archive,t=t1 --progress 5000 \
--statistics --charset=utf8mb4 --limit=10000 --txn-size 1000 --sleep 30
常用選項
--analyze
指定工具完成數據歸檔後對表執行'ANALYZE TABLE'操作。指定方法如'--analyze=ds'，s代表源端表，d代表目標端表，也可以單獨指定。
--ask-pass
命令行提示密碼輸入，保護密碼安全，前提需安裝模塊perl-TermReadKey。
--buffer
指定緩沖區數據刷新到選項'--file'指定的文件並且在提交時刷新。
只有當事務提交時禁用自動刷新到'--file'指定的文件和刷新文件到磁碟，這意味著文件是被操作系統塊進行刷新，因此在事務進行提交之前有一些數據隱式刷新到磁碟。默認是每一行操作後進行文件刷新到磁碟。
--bulk-delete
指定單個語句刪除chunk的方式來批量刪除行，會隱式執行選項'--commit-each'。
使用單個DELETE語句刪除每個chunk對應的錶行，通常的做法是通過主鍵進行逐行的刪除，批量刪除在速度上會有很大的提升，但如果有復雜的'WHERE'條件就可能會更慢。
--[no]bulk-delete-limit
默認值：yes
指定添加選項'--bulk-delete'和'--limit'到進行歸檔的語句中。
--bulk-insert
使用LOAD DATA LOCAL INFILE的方法，通過批量插入chunk的方式來插入行(隱式指定選項'--bulk-delete'和'--commit-each')
而不是通過逐行單獨插入的方式進行，它比單行執行INSERT語句插入的速度要快。通過隱式創建臨時表來存儲需要批量插入的行(chunk)，而不是直接進行批量插入操作，當臨時表中完成每個chunk之後再進行統一數據載入。為了保證數據的安全性，該選項會強制使用選項'--bulk-delete'，這樣能夠有效保證刪除是在插入完全成功之後進行的。
--channel
指定當主從復制環境是多源復制時需要進行歸檔哪個主庫的數據，適用於多源復制中多個主庫對應一個從庫的情形。
--charset，-A
指定連接字元集。
--[no]check-charset
默認值：yes
指定檢查確保資料庫連接時字元集和表字元集相同。
--[no]check-columns
默認值：yes
指定檢查確保選項'--source'指定的源端表和'--dest'指定的目標表具有相同的欄位。
不檢查欄位在表的排序和欄位類型，只檢查欄位是否在源端表和目標表當中都存在，如果有不相同的欄位差異，則工具報錯退出。如果需要禁用該檢查，則指定'--no-check-columns'。
--check-slave-lag
指定主從復制延遲大於選項'--max-lag'指定的值之後暫停歸檔操作。默認情況下，工具會檢查所有的從庫，但該選項只作用於指定的從庫(通過DSN連接方式)。
--check-interval
默認值：1s
如果同時指定了選項'--check-slave-lag'，則該選項指定的時間為工具發現主從復制延遲時暫停的時間。每進行操作100行時進行一次檢查。
--columns，-c
指定需要歸檔的表欄位，如有多個則用','(逗號)隔開。
--commit-each
指定按每次獲取和歸檔的行數進行提交，該選項會禁用選項'--txn-size'。
在每次獲取表數據並進行歸檔之後，在獲取下一次數據和選項'--sleep'指定的休眠時間之前，進行事務提交和刷新選項'--file'指定的文件，通過選項'--limit'控制事務的大小。
--host，-h
指定連接的資料庫IP地址。
--port，-P
指定連接的資料庫Port埠。
--user，-u
指定連接的資料庫用戶。
--password，-p
指定連接的資料庫用戶密碼。
--socket，-S
指定使用SOCKET文件連接。
--databases，-d
指定連接的資料庫
--source
指定需要進行歸檔操作的表，該選項是必須指定的選項，使用DSN方式表示。
--dest
指定要歸檔到的目標端表，使用DSN方式表示。
如果該選項沒有指定的話，則默認與選項'--source'指定源端表為相同表。
--where
指定通過WHERE條件語句指定需要歸檔的數據，該選項是必須指定的選項。不需要加上'WHERE'關鍵字，如果確實不需要WHERE條件進行限制，則指定'--where 1=1'。
--file
指定表數據需要歸檔到的文件。使用類似MySQL DATE_FORMAT()格式化命名方式。
文件內容與MySQL中SELECT INTO OUTFILE語句使用相同的格式，文件命名選項如下所示：
%Y：年，4位數(Year, numeric, four digits)
%m：月，2位數(Month, numeric (01..12))
%d：日，2位數(Day of the month, numeric (01..31))
%H：小時(Hour (00..23))
%i：分鍾(Minutes, numeric (00..59))
%s：秒(Seconds (00..59))
%D：資料庫名(Database name)
%t：表名(Table name)
二、原理解析
根據general log的輸出，我們整理出時序表格如下
三、其他說明
咋一看這個過程貌似也沒有什麼問題，但是，假如在原表掃描出數據，插入到新表的過程中，舊數據發生了變化怎麼辦？
帶著這個疑問，我們進行了源碼的跟蹤，我們在pt-archiver的6839行打上了斷點
然後我分別在幾個session窗口做了如下動作
最後pt-archiver輸出如下：
# A software update is available:
TIME ELAPSED COUNT
2020-04-08T09:13:21 0 0
2020-04-08T09:13:21 0 1
Started at 2020-04-08T09:13:21, ended at 2020-04-08T09:13:51
Source: A=utf8mb4,D=xucl,P=3306,h=127.0.0.1,p=...,t=t1,u=xucl
Dest: A=utf8mb4,D=xucl_archive,P=3306,h=127.0.0.1,p=...,t=t1,u=xucl
SELECT 1
INSERT 1
DELETE 1
Action Count Time Pct
sleep 1 30.0002 99.89
inserting 1 0.0213 0.07
commit 2 0.0080 0.03
select 2 0.0017 0.01
deleting 1 0.0005 0.00
other 0 0.0008 0.00
很明顯，id=3這條記錄並沒有進行歸檔（我們這里是改了條件列，實際生產中可能是更改了其他列，造成歸檔數據不準確）
那麼如何來解決這種情況的發生呢？
顯然，資料庫在資料庫中可以通過加排它鎖來防止其他程序修改對應的數據，pt-archiver其實早就已經幫我們考慮到了這樣的情況，pt-archiver提供了兩種選擇
--for-update：Adds the FOR UPDATE modifier to SELECT statements
--share-lock：Adds the LOCK IN SHARE MODE modifier to SELECT statements
四、總結
pt-archiver作為歸檔工具無疑是MySQL DBA日常運維的大利器之一，在使用過程中在知道如何使用的基礎上也能夠知曉其原理
歸檔過程中最好能對歸檔記錄進行加鎖操作，以免造成歸檔數據不準確
在主從環境中，歸檔過程最好控制速度，以免造成主從延遲
盡量控制好chunk的大小，不要過大，造成大事務
『貳』 B端產品員工管理優化及其歷史數據處理
總結一下最近做的一個優化點，由於涉及到底層的東西，所以在此優化中，歷史數據的處理是最麻煩的。有時我們認為最簡潔、大家一致認同的方案不一定是最適合的。
這里提到的是企業管理軟體中的員工管理與登錄賬號的管理。如果沒有過相關經驗不容易理解的話，可以聯想一下OA系統，我們身為公司的一員，需要在OA系統中處理一些公司的業務，我們擁有OA賬號。你的OA登錄後看到的內容一定與你的領導登錄系統看到的內容是不一樣的，因為你們擁有的許可權不同。同樣小王也是公司的一員，但其是基層員工，在OA系統中可以查到小王的基本信息，但小王並沒有OA的登錄許可權。
對於一款B端管理系統，系統要管理企業的所有員工，根據員工的不同崗位，管理員分配給員工不同的系統許可權，或者沒有系統許可權（即沒有系統的登錄賬號）。一些傳統的ERP軟體把這一點做的相當靈活，可能滿足很多極端的場景。事情是相對的，足夠的靈活，便要犧牲掉易用性，勢必會對用戶造成困擾。
上兩張圖是一些傳統的ERP的管理模式，先建立員工，員工有自己對應的崗位，然後建立賬號，每個賬號有對應的角色（角色可以理解為許可權的打包體，不同的賬號可以共用同一個角色，即擁有角色中包含的許可權，修改角色的許可權，則擁有該角色的賬號的許可權一並被修改），然後把員工與賬號綁定建立關系。這樣做就相當的靈活，員工與賬號是兩條獨立的線，最後把其關聯起來。員工不綁定賬號即代表此員工無系統的登錄賬號，賬號不綁定員工即可能這是一個管理員的賬號，沒有具體的人操作。
這樣做的缺點，一是操作復雜，一個員工如果要使用系統，其資料要到兩個地方建立，學習成本與維護成本高；二是容易造成混亂，一個員工給了銷售員的崗位，但在其綁定的賬號里卻給了收銀員的許可權。下圖是一個真實的案例，客戶實在是搞不明白員工、崗位、賬號、角色之間的關系，為了給員工某個許可權時，把所有的崗位都配給了該員工，但該員工仍沒有想要的許可權。
即然不同的崗位會擁有不同的許可權，那為什麼不在崗位上直接設置許可權呢，而在員工的創建時直接選擇是否開通登錄賬號，減少操作、減少客戶要接受的概念。
方案中，在新增員工時選擇是否開通登錄賬號，如果開通，則給出默認登錄賬號與密碼，無需客戶再設置；頁面左側可按崗位對員工進行篩選，然後可以對崗位進行許可權的設置。這樣客戶就可以在這一個頁面中完成員工與登錄賬號的維護，方便快捷，且不容易出錯。
優化後的整個流程的確是要整潔很多，但是我們這不是一個從零開始的系統，做這種大的改動時一定要考慮到歷史數據的處理。我們現有的客戶該怎麼辦？新的改版會對他們造成哪些影響？這就需要我們拿新的設計方案與原有的系統做比對，原有系統中的每一個欄位每一個概念，到新的設計中要怎麼體現。如角色，這個概念將在新的設計中消失，賬號列表也將不復存在，這樣的改動，歷史數據要怎麼呈現呢？老客戶對新的設計是否適應，是否需要重新學習？學習成本的高低？
為了處理歷史數據，對設計方案做出了調整，把賬號管理的入口放在員工管理頁面，使其弱化。之前賬號與角色的概念仍然存在，弱化賬號與角色的概念，減少點擊率。新增員工，如果開通登錄賬號，則賬號管理列表自動生成一個賬號；新增崗位時，便自動生成一個對應的角色，對崗位進行許可權的設置，即是對角色設置許可權。以前的邏輯仍在，仍能滿足老數據，對於新簽的客戶，只要建立崗位與員工即可，方便快捷。 而老客戶，在發版後第一次進入此頁面時，給出浮層提成，告知客戶這里的變化。
在開發之前，抽樣幾個老客戶進行了調研，客戶一致認為新的設計比之前更加簡潔、容易理解，並表示弱化賬號管理可以接受。
我在文章中只提取了主流程，實際上歷史數據的處理相當復雜，有些數據的處理是我們在前期做設計時考慮不到的，這就需要後期與開發人員再不斷的溝通，這種情況要提前與開發哥哥打好招呼，預留足夠的開發時間。
翻閱客戶數據，有時我們考慮的復雜的情況其實並不存在。如，沒有綁定員工的賬號，極少，數百家店 上千條的賬號里，只有十幾條賬號沒有綁定員工，其中三分之二的數據是因為之前復雜的流程造成的錯誤數據，已被禁用，剩餘的幾個是集團管理員的角色，這幾個賬號極少被使用到。通過與幾家客戶的溝通發現，他們使用系統是為了記錄，如果哪裡出錯了可以有據可尋，可以通過系統去查找哪個環節的錯，誰出的錯，如果賬號不綁定員工那就責任不到人了。雖然傳統ERP的方案很靈活，但使用起來不方便，容易把人繞暈，並且這所謂的靈活在實際的場景中並沒有被用到。
做B端產品最忌諱大而全，然而B端產品很容易被做的大而全，因為我們面對的是不同的客戶，客戶之間雖然有很多相似性，但他們也有自己的獨特性，一旦滿足不了他們的獨特性 我們將有可能失去該客戶，我們失去的極有可能是幾十萬、甚至上百萬的收款，而這直接關繫到KPI的完成，對於這種情況，領導會讓我們以客戶的需求優先。久而久之，基本功能加上各種獨特的功能，就成了一個大而全的系統了。有一定工作經驗的產品經理或者設計師，在做設計之前會考慮各種各樣的情況，這些情況可能是真的存在，也可能是我們虛構出來的。這就需要一些取捨了，根據對市場調研以及與行業專家的訪談，來定義我們產品功能的留舍。
企業管理軟體的體驗任重道遠，身為交互設計師，不僅要從頁面布局、層次結構等方面優化產品，更要了解行業，從整個操作流程上做優化！
『叄』 通達信如何復盤歷史數據
通達信復盤歷史數據：瀏覽器：電腦端：macbookpromos14打開google版本92.0.4515.131，打開網頁，右鍵你要復盤的股票，選擇沙盤推演，點擊開始就可以了。
一、利用通達信自帶的選股條件或自定義選股條件公式（如均線多頭排列、60日縮量、MACD底背離、突破底部橫盤等），就可以很方便的利用選股器把符合條件的股票給篩選出來。
二、通達信選股公式：AA:=MA(CLOSE，5);BB:=MA(CLOSE，10);CC:=MA(CLOSE，20);DD:=MA(CLOSE，60);T1:=AA>BBANDBB>CCANDCC>DD;COUNT(T1，5)=5;選股公式定義：是指從短周期到長周期均線，從上而下的依次排列，並且持續時間不少於5天。明確了選股公式定義，接下來就需要把這個選股模型能在果仁平台進行選股設置，然後即可做歷史數據回測。
三、主流板塊和板塊異動主流板塊至當天最受市場熱點關注的板塊，例如今日的熱點就集中在了半導體、蘋果三星、集成電路三大板塊；板塊異動指當天所對應的板塊出現了大資金的流入或者是流出，例如下圖，能夠看到個股在盤中所對應的板塊出現了快速拉漲、快速下跌的時間以及幅度，從而在盤中做出一個預警，這類信息對於散戶投資者來講可以在盤中及時排除一些帶有風險的個股，也可以讓我們及時的了解到市場中的風口方向；
持倉溫度和封板率。持倉溫度指的是當天股市中各路投資者對股市的交易情緒，溫度最高是100度，而最低是0度，熱度越高表明當天投資者在盤中交易的買進次數越多，表明對市場未來行情表示看好；封板率指的是當天股市中自然漲停的股票在盤中打開的次數，如果封板率在高位，就表明股票漲停之後打開的次數很少，主力資金出現出逃的可能性也低，如果封板率過低就表明當天主力很有可能出現大資金的出逃。