最近因原先的 MySQL 版本过低，所以希望将 Windows 下的 MySQL5.5 升级为 MySQL5.7。记录一下升级过程。 下载 MySQL MySQL 下载地址：https://dev.mysql.com/downloads/mysql/ MySQL 5.7.33.0：https://dev.mysql.com/downloads/file/?id=500616 移除旧版本 MySQL 管理员身份运行，先停止 MySQL 服务，然后移除 MySQL。 C:\WINDOWS\system32>cd C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin>mysqld --remove MySQL Failed to remove the service because the service is running Stop the service and try again C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin>net stop MySQL MySQL 服务正在停止. MySQL 服务已成功停止。 C:\Program Files (x86)\MySQL\MySQL Server 5.5\bin>mysqld --remove MySQL Service successfully removed. 如果报错 The service doesn't exist!，则需要在任务管理器 -> 服务中，查找一下具体的 MySQL 服务名 备份数据 将旧版本的 data 文件和 my.ini 文件复制至 5.7 路径下。 重命名旧版本安装目录，避免混淆。 查看并修改 my.ini 文件中的路径配置。 my.ini 配置后如下： #Path to installation directory. All paths are usually resolved relative to this. basedir="C:/Program Files (x86)/MySQL/mysql-5.7.33-win32/" #Path to the database root datadir="C:/ProgramData/MySQL/mysql-5.7.33-win32/Data/" 添加新 MySQL mysqld.exe --install MySQL 启动 MySQL： net start MySQL 问题解决 mysqld --console 打印如下： [ERROR] unknown variable 'table_cache=256' [ERROR] Aborting 去除 my.ini 文件中的 table_cache 属性配置。 [ERROR] unknown variable 'innodb_additional_mem_pool_size=2M' [ERROR] Aborting 去除 my.ini 文件中的 innodb_additional_mem_pool_size 属性配置。 升级 MySQL mysql_upgrade -uroot -p 重新启动 MySQL 服务： 至此，MySQL 升级就算完成了。 验证 MySQL 新版本： 相关文章 Linux安装MySQL7版本 Windows 安装 MySQL8 版本 MySQL操作Json数据相关使用总结 使用 binlog2sql 恢复 MySQL 数据 MySQL 密码过期的修改方法

什么是backlog backlog是linux下socket函数之listen的参数，当应用程序调用listen系统调用让一个socket进入LISTEN状态时，需要指定一个backlog参数。这个参数经常被描述为，新连接队列的长度限制。 由于TCP建立连接需要进行3次握手，一个新连接在到达ESTABLISHED状态可以被accept系统调用返回给应用程序前，必须经过一个中间状态SYN RECEIVED。这意味着，TCP/IP协议栈在实现backlog队列时，有两种不同的选择： 仅使用一个队列，队列规模由listen系统调用backlog参数指定。当协议栈收到一个SYN包时，响应SYN/ACK包并且将连接加进该队列。当相应的ACK响应包收到后，连接变为ESTABLISHED状态，可以向应用程序返回。这意味着队列里的连接可以有两种不同的状态：SEND RECEIVED和ESTABLISHED。只有后一种连接才能被accept系统调用返回给应用程序。 使用两个队列——SYN队列(待完成连接队列)和accept队列(已完成连接队列)。状态为SYN RECEIVED的连接进入SYN队列，后续当状态变更为ESTABLISHED时移到accept队列(即收到3次握手中最后一个ACK包)。顾名思义，accept系统调用就只是简单地从accept队列消费新连接。在这种情况下，listen系统调用backlog参数决定accept队列的最大规模。 对于linux操作系统，内核在2.2之后的版本，tcp/ip协议实现了第二种方案，即一个syn队列，一个accept队列，syn队列的长度由系统级别设置，accept队列的长度可以由应用级别设置，tcp建连交互流程如下图所示： client 端使用 connect() 向 server 端发起连接请求（发送 syn 包），此时 client 端的 TCP 的状态为 SYN_SENT。 server 端在收到 syn 包后，将 TCP 相关信息放到 syn queue（半连接队列）中，同时向 client 发送 syn+ack，server 端 TCP 的状态为 SYN_RCVD。 client 端收到 server 端的 syn+ack 后，向 server 端发送 ack，此时 client 端的 TCP 的状态为 ESTABLISHED。Server 端收到 ack 确认后，从 syn queue 里将 TCP 信息取出，并放到 accept queue（全连接队列）中，此时 server 端的 TCP 的状态为 ESTABLISHED。 经过以上三个过程，client 端和 server 端建立了连接，即所谓三次握手的过程。 由此，我们已经知道了什么是backlog，以及半连接队列、全连接队列的由来。下文当中提到的backlog均表示全连接队列长度。那怎么设置backlog的值呢？ 如何设置backlog backlog的大小有两方面因素决定，一是系统层面，二是应用层面 系统层面：somaxconn参数，可以通过编辑/proc/

1、概念 用例图是描述用例、参与者以及它们之间关系的图。 用例图是从用户的角度来描述对信息系统的需求，分析产品的功能和行为。 用例图定义和描述了系统的外部可见行为，是分析、设计直至组装测试的重要依据。 用例图由如下几个概念组成： 参与者actor：角色，系统的用户； 系统边界system scope：确定系统的范围，边界是一个方框，用例在边界内，参与者在边界外； 用例use case：系统提供的服务； 关联association：参与者与用例间的关系。 2、什么是参与者？ 参与者是指在系统之外，但与系统直接交互的对象，即actor，也叫执行者、活动者。 参与者用人形符号表示，在人形符号下面标出参与者的角色名。参与者不止是人员，也有可能是信息系统、设备。 actor 3、什么是用例？ 用例是用户期望系统具备的功能，每一个用例说明一个系统提供给它的使用者的一种服务或功能。 用例的目标是要定义系统的一个行为，但并不显示系统的内部结构。 用例名一般为动宾短语，符号是椭圆加用例名（Visio中用例名写在椭圆内）。 4、如何寻找和确定用例？ 参与者需要从系统中获取哪种功能？ 参与者是否需要读取、产生、删除、修改或存储系统中的某种信息？ 系统的状态改变时，是否通知参与者？ 是否存在影响系统的外部事件？ 系统需要什么样的输入与输出？ 邮件用例 5、用例描述 用例图没有描述系统行为的细节，所以需要以书面文档的形式对用例进行描述。至少包括： 名称：与用例图中的名称保持一致； 标识符：用例的代码或编号； 基本操作流程：描述各项工作都正常进行时用例的工作方式； 可选操作流程：很少使用、异常情况、发出错误的情况。 用例描述 另外还能包括：用例概述、范围、参与者、前置条件、后置条件、子事件流、规则与约束等。 6、用例图中的各种关系 a）参与者与用例间的关联关系：参与者与用例之间的通信，也成为关联或通信关系。 关联关系 b）用例与用例之间的关系：包含关系（include）、扩展关系（extend）、泛化关系。 7、包含关系 包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。表示符号：<<include>> 包含关系 实例一 实例二 8、扩展关系 用一个用例（可选）扩展另一个用例（基本例）的功能，将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。表示符号：<<extend>>。 实例 9、泛化关系 子用例继承了父用例所有的结构

A few years ago Peter Zaitsev, in a post titled “To UUID or not to UUID,” wrote: “There is timestamp based part in UUID which has similar properties to auto_increment and which could be used to have values generated at the same point in time physically local in BTREE index.” For this post, I’ve rearranged the timestamp part of UUID (Universal Unique Identifier) and did some benchmarks. Many people store UUID as char (36) and use as row identity value (PRIMARY KEY) because it is unique across every table, every database and every server and allow easy merging of records from different databases. But here comes the problem, using it as PRIMARY KEY causes the problems described below. Problems with UUID UUID has 36 characters which make it bulky. InnoDB stores data in the PRIMARY KEY order and all the secondary keys also contain PRIMARY KEY. So having UUID as PRIMARY KEY makes the index bigger which cannot be fit into the memory Inserts are random and the data is scattered. Despite the problems with UUID, people still prefer it because it is UNIQUE across every table, can be generated anywhere. In this blog, I will explain how to store UUID in an efficient way by re-arranging timestamp part of UUID. Structure of UUID MySQL uses UUID version 1 which is a 128-bit number represented by a utf8 string of five hexadecimal numbers The first three numbers are generated from a timestamp. The fourth number preserves temporal uniqueness in case the timestamp value loses monotonicity (for example, due to daylight saving time). The fifth number is an IEEE 802 node number that provides spatial uniqueness. A random number is substituted if the latter is not available (for example, because the host computer has no Ethernet card, or we do not know how to find the hardware address of an interface on your operating system). In this case, spatial uniqueness cannot be guaranteed. Nevertheless, a collision should have a very low probability. The timestamp is mapped as follows: When the

为啥突然要写这么一个题目呢？ 因为职业并不是HRor猎头的倪叔，过去的2年一直都在帮朋友找工作，而其中很多人都是拥有互联网大厂背景的。 当然，倪叔的朋友们最终都找到了下家，但除开个别在企业核心岗位，掌握稀缺资源的幸运儿之外，对于大多数人来说： 一方面，过程普遍都很漫长，互联网进入寒冬之后，家家都在精简人员，招聘的需求相当有限，核心岗位更是一坑难求。 因而当大家跳出来的时候，发现远没有想象中那么受欢迎； 另一方面，最终的归属，无论从待遇，还是公司发展，还是团队人员质素，相比于前东家来说也谈不上理想，往往只能作为个人在这两年动荡时期的过渡选择。 而且，薪资待遇上大部分都只能做到平薪调动，这个时节还能涨薪的也是少数。 在过去的两年中，对于身边还在大厂工作的朋友，倪叔给出的工作建议都是：能不出来就尽量不要出来，在整个行业的下行时期，大厂是最好的避风港。 但建议归建议，整个2019年发生工作变动的朋友还是不少的。因为整个互联网行业下行的变动必然深刻的影响着每一家公司。 创业公司倒闭裁员自是不在话下，而身处大厂，虽然未必有裁员优化的威胁，但市场变化对行业巨头的业绩影响是惊人。 而要对抗这种影响，就势必造成内部压强的放大：难以完成的业绩目标，极其严苛的考核要求，长期的熬夜加班等等都会给个体施加巨大的压力。 再结合上长期以来的上升空间受限，人事关系复杂等等老问题就非常容易促使人做出离职的决定，但结合外部环境来看，这时候决定往往不是好的选择。 原本以为熬过了2019年就是胜利，哪知道2020年又是一个“地狱模式”的开局，很多与线下有关的业务都面临冲击。 再加上财年末的末尾淘汰和组织架构调整带来的人事变动，又造成了新一波的人员变动。 就在这几天，倪叔又开始接到一些朋友的电话，说想通过倪叔看看外面的机会，然后倪叔又开始balabala，苦口婆心的劝对方不要乱动，保住现在的工作…… 而在接到了第四通类似主题的电话之后，倪叔觉得有必要通过一篇文章来让大家意识到： 虽然大家都是大厂员工，都非常优秀，但这一次外界的环境真的不同了，企业和人才之间的供需关系发生根本性的改变。 以前是企业需要人才，现在是人才更需要企业的历史时期。 01现在人才更需要企业 为了加深大家对“现在人才更需要企业”这个结论的理解，说几个倪叔自己的亲身经历： 在2019年，一个有BAT背景，后在独角兽担任高级总监的朋友，因为家庭原因要换城市，让倪叔帮忙找工作。 而让倪叔没有想到的