mysql

灵魂三问： 2020年你涨薪了吗？ 2020年你的技术提升了吗？ 对于2020年的自己是否满意？ “金三银四”即将到来，作为一年的跳槽季，这是找工作换工作的最佳时机，对于不满现状的朋友考虑在这个时间跳槽，但是看看招聘网站，要求玄的要死。面试几轮之后更是没有深没有浅。经过一段时间的接触之后，内心十分着急，又不知道怎么办，就是没有一个具体可执行的计划。这样下去导致最坏的结果可能是今年的跳槽可能变成了换坑，跳槽是职业生涯有续线性的增长，无论收入还是title或者平台，换坑是从这个坑跳到另外一个坑，从而进入一个恶性循环，给长期职业发展带来很不利的影响，个人能力的成长长期维持在同一水平线上下浮动。 计划的意思是了解当下市场招聘环境的变化，并且根据对自己技术势力的综合评估对当前的市场行情的预估之后，分析技术差距罗列的一个学习列表，具体细节的实施，学习效果的验证，要花费多长时间来完成他，每天要投入多少精力学习等等，根据不同的情况来自己把握。 首先给大家分享一份对标腾讯T8(原2.3)职级的技术栈，供大家查漏补缺 c/c++ linux服务器开发学习地址： c/c++ linux服务器高级架构师 一、精进基石 1、数据结构与算法 2、设计模式23种（没有全部列举） 3、工程管理 视频学习地址： 设计模式很难吗？看mark老师如何吊打设计模式 红黑树，在Linux内核的那些故事 二、高性能网络设计

“ Insert into select 请慎用，同事因为使用了 Insert into select 语句引发了重大生产事故，最后被开除。 图片来自 Pexels 某天 xxx 接到一个需求，需要将表 A 的数据迁移到表 B 中去做一个备份。他本想通过程序先查询查出来然后批量插入，但 xxx 觉得这样有点慢，需要耗费大量的网络 I/O，决定采取别的方法进行实现。 通过在某度的海洋里遨游，他发现了可以使用 insert into select 实现，这样就可以避免使用网络 I/O，直接使用 SQL 依靠数据库 I/O 完成，这样简直不要太棒， 然后他就被开除了。 事故发生的经过 由于数据数据库中 order_today 数据量过大，当时好像有 700W 了，并且每天在以 30W 的速度增加。 所以上司命令 xxx 将 order_today 内的部分数据迁移到 order_record 中，并将 order_today 中的数据删除，这样来降低 order_today 表中的数据量。 由于考虑到会占用数据库 I/O，为了不影响业务，计划是 9：00 以后开始迁移，但是 xxx 在 8：00 的时候，尝试迁移了少部分数据（1000 条），觉得没啥问题，就开始考虑大批量迁移。 在迁移的过程中，应急群是先反应有小部分用户出现支付失败，随后反应大批用户出现支付失败的情况

前期准备 mysql模型:test_max_date(id int,name varchar(255)，num int,date date) hive模型： create table test_date_max(id int,name string,rq Date); insert into table test_date_max values (1,"1","2020-12-25"), (2,"1","2020-12-28"), (3,"2","2020-12-25"), (4,"2","2020-12-20") ; 需求 查询每个人最新状态 计算逻辑 每个人有多条数据，日期越大，状态越新 计算过程 mysql: SELECT id,name,date,max(date) from test_max_date group by name ORDER BY id hive: select name,max(rq) from test_date_max group by name; 错误信息说明：在之前的帖子中说过hive groupby的问题。 这里hive中有id,name,日期。id是主键不重复，name是可以重复的，按照name分组，对rq使用max函数，其实是对name去重，返回name每个重复值组中的最大日期 就好比一个公司分了几个部门，部门是确定的