使用工具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度，热度越高表明当天投资者在盘中交易的买进次数越多，表明对市场未来行情表示看好；封板率指的是当天股市中自然涨停的股票在盘中打开的次数，如果封板率在高位，就表明股票涨停之后打开的次数很少，主力资金出现出逃的可能性也低，如果封板率过低就表明当天主力很有可能出现大资金的出逃。