Yusher's Blog

Solution:cannot load such file -- openssl (LoadError)

Wed, 08 Jan 2020 12:30:11 +0000

问题

在linux环境下，手动安装ruby时，会报如下错误：

cannot load such file -- openssl (LoadError)

解决方案

cd /ruby-dir/ext/openssl #进入ruby的安装包目录
ruby extconf.rb
make && make install

Solution:docker用户权限解决方案

Wed, 08 Jan 2020 11:22:11 +0000

问题

非root用户执行docker相关命令时，会出现如下错误：

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.39/containers/json: dial unix /var/run/docker.sock: connect: permission denied

原因

docker进程使用Unix Socket而不是使用TCP端口，而默认情况下，Unix Socket属于root用户，所以非root用户不能访问。

解决方案

使用sudo命令
```
sudo docker ps -a
```
缺点：每次带sudo不方便，还得输密码。

将用户加入docker用户组

sudo gpasswd -a $USER docker #将当前用户加入docker组
newgrp docker #更新用户组
docker ps -a #docker命令

原因：安装docker时，会创建docker用户组，会默认赋予Unix Socket的权限。

秒杀产品的理解与应对

Thu, 19 Sep 2019 11:22:11 +0000

概述

本文记录自己对秒杀场景的理解与应对措施。

特征

秒杀主要发生在电商活动中，商家通过采取低价促销或者饥饿营销，提供较低廉的价格或有限的数量给大量用户抢购，想以此提升自身平台的口碑及增加部分品牌的曝光度。

由于关注度很高，用户量在活动开始前后一段时间出现激增的情况，通常会是平常的数十倍乃至上百倍，因此若不处理得当，很容易造成平台服务器奔溃，严重影响用户体验。

秒杀活动主要有三个阶段存在大流量访问：

秒杀前: 用户停留在活动页面，不断进行页面刷新，页面请求达到峰值。
秒杀中: 用户不断点击购买按钮，购买请求达到峰值。
秒杀后: 大部分用户未抢到商品，不断刷新页面等待其他用户退单，页面请求再次飙升。

应对措施

客户端

CDN: 静态资源存在CDN上。
浏览器缓存: 针对秒杀商品页面采取页面缓存，静态数据缓存在浏览器上。
前端JS: 抢购按钮置灰，通过JS脚本进行倒计时处理，到时解除点击限制；也可加入限制x秒内允许一次提交。

服务端

Nginx: 按连接数限流(ngx_http_limit_conn_module)、按请求速率限流(ngx_http_limit_req_module)。
用户唯一标识: 限制用户必须为注册用户，严格点可以要求用绑定手机号或身份证等信息，但这可能会造成伤敌一千自损八百的后果。
读写分离: 将秒杀商品信息缓存至Redis，提供读实例；根据goods_status状态来判断抢购是否开始；根据goods_left=goods_count-goods_bought_num的值来判断是否允许下单。
```
// 秒杀商品
{
    "goods_count": 100, // 商品库存数量
    "goods_status": 0, // 商品抢购状态
    "goods_bought_num": 0, // 商品已抢数量
}
```

库存扣量: 下单成功后，需要对库存量进行更新，这里使用Redis的Lua脚本来保证多个命令的原子性。

-- 库存更新lua脚本
local key = ARGV[1];
local buy_num = tonumber(ARGV[2]);
--[[ 若商品量大，则传入以下参数，供异步入库
local user_id = tonumber(ARGV[3]);
local goods_id = tonumber(ARGV[4]);
]]
    
if not buy_num or buy_num == 0 then
    return 0;
end
    
local goods_vals = redis.call("HMGET", key, "goods_count", "goods_bought_num");
local goods_count = tonumber(goods_vals[1]);
local goods_bought_num = tonumber(goods_vals[2]);
    
if not goods_count or not goods_bought_num then
    return 0;
end
    
if buy_num <= goods_count - goods_bought_num then
    redis.call("HINCRBY", key, "goods_bought_num", buy_num);
    --[[ 异步入库代码
    local order_info = json.encode({uid: user_id, goods_id: goods_id, buy_num: buy_num, order_time: os.time()});
    redis.call("LPUSH", "order_list:"..goods_id, order_info);
    ]]
    -- 
    return buy_num;
end
return 0;

数据层

下单入库: 若秒杀商品较少时，可以直接操作数据库，若商品较多数以万计的话，直接入库会给数据库带来极大压力甚至导致奔溃，因此可以先将订单信息入Redis队列，采用异步消费入库。

// 订单详情 order_list:good_id
{
    "uid": 123, // 用户id
    "goods_id": 456, // 商品id
    "buy_num": 1, // 购买数量
    "order_time": 1234567890, // 下单时间
    // 其他信息
}

redis> RPOP order_list:goods_id

付款处理: 一般秒杀商品下单成功后，系统会给用户一定的付款时间，如十五分钟，这样可以缓解支付服务端的压力。若中途用户取消订单或者超时，系统将更新goods_bought_num，那些还在不断刷新抢购商品页面的用户就能重新下单了。
结束抢购: 系统会在活动时间内定时计算数据库中的付款数量是否达到秒杀的库存数，若已达，则更新goods_status标记为活动结束。

扩展补充

Redis队列+集合

消费队列时，根据SISMEMBER odrer_user_list uid与RPOP goods_queue:goods_id结果做判断。

队列: 提前将商品库存存入队列中，然后依次消费库存。
集合: 用于存放用户唯一标识，若用户不在集合中，则允许调用消费程序；若超时付款或者取消付款，则移除。

MySQL-count语法使用与对比

Tue, 17 Sep 2019 07:22:46 +0000

概述

本文将对MySQL的count(1), count(*), count(column)进行对比分析。

作用与区别

作用

count(1): 统计表中所有记录数，包括字段为null的记录。
count(*): 与count(1)作用相同，统计表中所有记录，包括字段为null的记录。
count(column): 统计该字段在表中出现的次数，忽略该字段为null的记录，但不会忽略0或空字符串的记录。

区别

count(column)中的column若不为primary key时，会忽略column为null的记录。
效率上count(*)与count(1)相差不大，count(pk)次之，count(non-index)最慢。

验证-数据表无null值或空值

表结构

count结果

count对比图

验证-数据表存在null值或者空值

更新部分字段为null或空值

count结果

count对比图

验证-name字段具有索引

添加name字段索引

count对比图

MySQL Join的使用介绍

Wed, 11 Sep 2019 08:22:46 +0000

概述

本文将介绍MySQL的各种Join的使用方式。

表结构与数据

table1

id	name
1	Rose
2	Kobe
8	John

table2

id	name
1	Wade
2	Kobe
3	Durant
4	Curry

Join使用类型

内联接(INNER JOIN)

图示

SQL语句

# inner join
SELECT a.*, b.* FROM table1 a
INNER JOIN table2 b ON a.id = b.id;

结果

id	name	id(1)	name(1)
1	Rose	1	Wade
2	Kobe	2	Kobe

左连接(LEFT [OUTER] JOIN)

图示

Sql语句

# left join
SELECT a.*, b.* FROM table1 a
LEFT JOIN table2 b ON a.id = b.id;

结果

id	name	id(1)	name(1)
1	Rose	1	Wade
2	Kobe	2	Kobe
8	John	Null	Null

右连接(RIGHT [OUTER] JOIN)

图示

SQL语句

# right-join
SELECT a.*, b.* FROM table1 a
RIGHT JOIN table2 b ON a.id = b.id;

结果

id	name	id(1)	name(1)
1	Rose	1	Wade
2	Kobe	2	Kobe
Null	Null	3	Durant
Null	Null	4	Curry

差集(Intersect)

图示

SQL语句

# intersection: table1 - table2(属于table1但不属于table2)
SELECT a.*, b.* FROM table1 a
LEFT JOIN table2 b ON a.id = b.id
WHERE b.id IS NULL

结果

id	name	id(1)	name(1)
8	John	Null	Null

图示

SQL语句

# intersection: table2 - table1(属于table2但不属于table1)
SELECT a.*, b.* FROM table1 a
RIGHT JOIN table2 b ON a.id = b.id
WHERE a.id IS NULL;

结果

id	name	id(1)	name(1)
Null	Null	3	Durant
Null	Null	4	Curry

并集(UNION)

图示

SQL语句

# union join
SELECT a.*, b.* FROM table1 a
LEFT JOIN table2 b ON a.id = b.id
UNION
SELECT a.*, b.* FROM table1 a
RIGHT JOIN table2 b ON a.id = b.id;

结果

id	name	id(1)	name(1)
1	Rose	1	Wade
2	Kobe	2	Kobe
8	John	Null	Null
Null	Null	3	Durant
Null	Null	4	Curry

对称差(Semmetric Difference)

图示

SQL语句

# symmetric difference
SELECT a.*, b.* FROM table1 a
LEFT JOIN table2 b ON a.id = b.id
WHERE b.id IS NULL
UNION
SELECT a.*, b.* FROM table1 a
RIGHT JOIN table2 b ON a.id = b.id
WHERE a.id IS NULL;

结果

id	name	id(1)	name(1)
8	John	Null	Null
Null	Null	3	Durant
Null	Null	4	Curry

Apache vs Nginx(实际考虑因素对比)

Wed, 21 Aug 2019 08:55:46 +0000

原文地址：https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations

引言

Apache和Nginx是世界上最常见的两种开源Web服务器。他们共同负责于为互联网上超过50%的流量提供服务。这两种解决方案都能处理各种工作负载，并能够与其他软件一同提供完整web栈(套件)。

虽然Apache和Nginx有许多共性，但是不应该认为它俩是可以完全互相替换的。二者各有所长，根据不同场景，您可能需要重新评估您的Web服务器选择，理解这点是很重要的。本文将专门讨论每种服务器如何在各个领域中表现。

总体概述

在我们深入对比Apache和Nginx的差异前，让我们快速了回顾下两个项目的背景及一般特性。

Apache

Apache HTTP Server由Robert McCool创建于1995年，1999年后一直在Apache Software Foundation主导下发展。由于HTTP Web服务器该基金的原始项目且是迄今为止最受欢迎的软件之一，所以经常被简称为”Apache”。

自1996年以来，Apache一直是互联网上最受欢迎的服务器。由于这种流行，Apache受益于优秀的文档和其他软件项目的全面支持。

由于它的灵活性，功能强大和广泛支持，Apache经常是管理员的首选。它可以通过动态加载的模块系统进行扩展，并可以处理大量的解释型语言而无需连接到单独的软件。

Nginx

在2002年，Igor Sysoev开始开发Nginx来作为解决C10K问题的答案，对于现代Web的要求来说，开始处理一万并发连接对Web服务器是个挑战。Nginx的最初公开版本发布于2004年，它通过依赖异步、事件驱动的架构来实现这个目标。

Nginx自发布以来越来越受欢迎，归根于它的轻量级资源利用率以及能够在最小硬件下轻松扩展的特点。Nginx擅长处理快速提供静态内容，旨在将动态请求转递至更适合这些请求目的的其他软件。

Nginx经常被管理员选择来提高资源效率和负载响应能力。倡导者鼓励Nginx专注于核心Web服务器及代理功能。

连接处理架构

Apache和Nginx之间的一个重要区别是如何处理连接和流量的实际方式。这可能是他们如何对不通流量状况做出响应的最显著差异。

Apache

Apache提供了各种多进程处理模块(MPMs)，它们决定着客户端请求如何被处理。总体来说，MPMs允许管理员轻松地切换连接处理架构。具体架构如下：

mpm_prefork： 此进程模块用于生成进程，该生成的进程仅有一个线程且用于处理请求。一个子进程只能处理一个连接。只要请求数小于进程数，该MPM模式是非常快的。然而，当请求数超过进程数时，性能就会迅速下降，所以在很多场景下，它不是个好的选择。每个进程都会对内存(RAM)消耗产生显著影响，所以该MPM模式难以被有效扩展。然而请记住，与其他不产生线程的组件配合使用仍然是个不错的选择。例如，PHP是非线程安全的，所以该MPM模式是唯一被推荐与mod_php(用于处理这些文件的Apache模块)一同使用的安全方式。
mpm_worker: 该模式产生可以管理多个线程的进程。每个线程可以单独处理一个连接。因为线程的效率优于进程，这意味着该MPM模式比mpm_prefork模式易于扩展。由于线程数量对于进程，这也意味着新的连接可以立即获得空闲线程，而不必等待空闲进程。
mpm_event: 再大多数情况下，该模式与mpm_prefork是类似的，但是它是经过优化的用于处理保持活跃的(keep-alive)连接。当使用mpm_worker模式时，只要连接是保持活跃状态，不管是否正在进行请求，它都将占用着一个线程。mpm_event模式通过留出专门的线程来处理保持活跃的连接并将活动的请求转交给其他线程。这样可以防止因保持活跃请求而陷入困境，从而加快执行效率。随着Apache2.4版本的发布，该特性已被标记为稳定。

如你所见，Apache提供了灵活的框架给供用户选择不同的连接及请求处理算法。所提供的选择主要取决于服务器的发展变革以及随着互联网环境变化对并发性需求的增加程度。

Nginx

Nginx随着Apache面临着大规模网站的并发问题场景而面世。鉴于这些考虑，Nginx从一开始就被设计为使用异步、非阻塞、事件驱动的连接处理算法。

Nginx产生worker进程，每个进程可以处理数千个连接。worker进程通过实现快速的循环机制来持续检查并处理事件来实现此特性。将实际的工作与连接分离，并允许每个worker仅在新的事件被触发时才去关注自己的连接。

由worker处理的每个连接都被放置在事件循环中，该事件循环与其他连接共用。在循环中，事件以异步方式处理，并允许非阻塞方式工作。当连接关闭，及被移出循环。

这种连接的处理方式允许Nginx在有限资源的情况下进行令人难以置信的扩展。由于服务器是单线程的且新的连接处理无需产生新的进程，因此即使在负载很重的时候，服务器内存与CPU利用率也能保持相对一致。

静态与动态内容对比

就实际使用情况而言，Apache与Nginx的最常见的一项对比在于每个服务器处理静态和动态内容请求的方式。

Apache

Apache服务器可以使用其传统的基于文件的方法来处理静态内容。这些操作的性能表现主要取决于上面所描述MPM方法。

Apache也可以通过嵌入相关语言的处理器到它的worker实例来处理动态内容。这就允许它可以在无需依赖外部组件的情况下，在Web服务器内执行动态内容。可以通过开启动态加载模块来启用这个功能(动态处理器)。

Apache具有在内部处理动态内容的能力意味着动态处理器的配置趋于简单化。通信则不需要借助额外软件协调，并且若内容需求变更，模块可以轻松地被替换。

Nginx

Nginx天生就不具备任何处理动态内容的能力。为了处理PHP和其他动态内容请求，Nginx必须将请求传递给外部处理器执行并等待渲染后的内容返回。最终结果可以被转发至客户端。

对管理员来说，这意味着Nginx必须通过它能识别的协议(http，FastCGI，SCGI，uWSGI，memcache)之一与处理器进行通信。这可能会略感复杂，特别是在尝试预测允许的连接数时，因为每次调用处理器都将造成额外的连接。

然而，这种方式也是有优势的。由于动态解析器并未嵌入在worker进程里，因此它的开销仅存在于动态内容(请求中)。静态内容可以被直接提供，解释器只有在需要时被使用。Apache也可以以这种方式运行，但是这样就失去了上部分描述的优点了。

分布式和集中式配置对比

对于管理员来说，二者最显著的区别之一在于内容目录中是否允许目录级别配置。

Apache

Apache包含一个选项，该选项允许在每个目录的基础上加入额外配置(检查和解析该目录本身内隐藏文件中的指令)。这些(隐藏)文件称之为.htaccess。

由于这些文件存在于内容目录中，当处理请求时，Apache会检查请求目标文件的每个组件中所包含的.htaccess文件并应用该文件中对应的指令。这可以有效地允许将配置分散在Web服务器中，经常用于实现路由重写(URL rewrites)、访问限制(access restrictions)、授权于认证(authorization and authentication)甚至缓存策略(caching policies)。

尽管上述例子可以在Apache主配置文件中设置，.htaccess文件仍然有其他优势。首先，因为这些在请求路径下的文件每次都会被解析，所以在无需重新加载服务器的情况下就能立即生效。其次，它使得允许非特权用户通过控制自身特定层面而无需授权完整的配置文件的权限成为可能。

这为一些Web软件(如内容管理系统)提供了一种简单的方法来配置它们的环境，无需提供对核心配置文件的访问权限。这使得共享主机提供者可以保持对主要配置的控制，而只需给客户端特定目录权限即可。

Nginx

Nginx既不解析.htaccess文件也不提供任何解析主配置文件之外的每个目录配置的机制。这可能不如Apache模型灵活，但是它具有自己的优势。

与.htaccess目录级别配置系统的最显著改进是性能提升。对于一个典型的允许任何目录存在.htaccess文件的Apache设置，服务器将针对每个请求来检查能到达目标文件的各个父级目录下的(.htaccess)文件。若在搜索过程中发现一个或多个.htaccess文件的话，就必须读取并解析它们。通过不允许目录覆盖，Nginx可以只进行单目录查找和文件读取来更快地处理每个请求(假设该文件在常规的目录结构中找到)。

另一个优势与安全性相关。分发目录级别的配置访问权限仍将安全责任分配给独立用户，这些用户能够完好的处理任务也是不被信任的。确保管理员来维护整个Web服务器的控制权可以防止在权限被授予给其他人的情况下的安全性错误发生。

请记住，若这些问题引起你的共鸣，在Apache中是支持关闭.htaccess文件解析的。

文件解析与基于URI解析的对比

Web服务器如何解析请求并映射到系统的实际资源上是这两个服务器另一个不同点。

Apache

Apache提供了将一个请求解释为文件系统上的物理资源或一个需要更抽象评估的URI地址的能力。通常情况下，对于前者Apache使用<Directory>或<Files>块，而后者利用<Location>来获取更抽象的资源。

由于Apache一开始就是为Web服务器设计的，所以默认情况下请求通常都是被解析成文件系统资源。首先是获取文档根目录，并在主机和端口号后附加请求部分来尝试找到实际文件。基本上，Web上文件系统的层次结构表示为可用的文档树。

虽然Apache具有在底层文件系统和网站空间上运行的能力，但它仍倾向于文件系统方法。这些可以通过一些设计决策来印证，包括基于每个目录配置的.htaccess文件的使用。Apache文档警告称：当请求映射到底层文件系统时，不要使用基于URI块的方式来限制访问。

Nginx

Nginx既是Web服务器也是代理服务器。归根于这两个角色的所需的体系结构，它主要适用于URIs，仅必要时转换为文件系统。

这些可以在一些构造和解析Nginx配置文件的方式中得到印证。Nginx不提供针对文件系统目录的特定配置的机制，取而代之的是解析自身URI。

例如，Nginx的主要配置块是server和location。server模块负责解析主机域名部分，而location块负责匹配主机域名及端口之后的URI部分。此时，请求是被解析为URI而不是文件系统上的一个地址。

对于静态文件，所有的请求最终都将被映射至文件系统上的一个地址上。首先，Nginx选择将处理对应请求的server块和location块，然后将根目录与URI进行组合，根据特定的配置调整任何必要的东西。

这个看起来很相似，但是将请求主要解析为URIs而不是文件系统位置，这允许Nginx能够更容易地在Web，邮件和代理服务器角色中起作用。Nginx通过简单的配置来响应不同的请求模式。在准备好为请求提供服务之前，Nginx是不会检查文件系统的，这也就解释了它为什么没有实现以.htaccess文件作为配置的方式。

模块

Nginx和Apache都是通过模块系统进行扩展的，但是二者的工作方式有着显著的差异。

Apache

Apache的模块系统允许你动态加载或卸载模块来满足你在服务器运行期间做出调整的需求。Apache的核心在于它可以一直运行，同时模块可以打开或关闭、添加或移除附加功能并关联至主服务器上。

Apache将这个功能特性运用各种任务中。归因与该平台的成熟性，有许多模块库可供使用。这些库可以被用于改变服务器的一些核心功能，如mod_php，它可以将PHP解析器嵌入至每个运行的worker中。

然而，模块不仅限于处理动态内容。它还能提供其他功能，如可以用于重写路由(rewriting URLs)、客户端认证(authenticating clients)、强化服务器(hardening the server)、日志(logging)、缓存(caching)、压缩(compression)、代理(proxying)、限速(rate limiting)和加密(encrypting)。动态模块可以在无需额外的工作情况下对核心功能进行扩展。

Nginx

Nginx也实现了模块系统，但是与Apache截然不同。在Nginx中，模块不是动态加载的，所以所需模块必须被编译至核心软件中。

对于许多用户来说，这将使得Nginx的灵活性降低。对于那些不习惯在其传统的发行版软件包系统之外维护他们自己编译的软件的用户来说确实如此。虽然发行版的软件包往往都已包含了比较常用的模块，但是如果你需要非标准的模块，则必须自己根据源代码来构建服务器。

尽管如此，Nginx的模块仍是非常有用的，它允许你只需包含你打算使用的功能模块来指示服务器所需内容。一些用户也可能认为这样更安全，因为任何组件都无法直接被关联至服务器。然而，如果你的服务器可以做到这点，那你的服务器大概率已经受损。 Nginx的模块提供着许多与Apache模块相同的功能。如Nginx模块提供代理支持(proxying support)、压缩(compression)、限速(rate limiting)、日志(logging)、重写(rewriting)、地理位置(geolocation)、认证(authentication)、加密(encryption)、流传输(streaming)和邮件(mail)等功能。

支持、兼容性、生态系统与文档

需要考虑的关键点是，启动和运行的实际过程将在其他软件中获得可用怎样的帮助和支持前景。

Apache

由于Apache已经流行很久了，所以对该服务器的支持已相当普遍。有一大堆第一方及第三方文档库，可用于核心服务器和基于任务(Apache与其他软件挂钩使用)的场景。

除文档之外，许多工具和Web项目在Apache环境中包含自行引导工具。这可能会包含在项目自身中或在你发行版软件包团队所维护的包中。

总体来说，Apache仅因为它的市场份额及面世时间久的缘故而获得第三方项目的支持。管理员对Apache有更多的使用经验不是因为它的流行程度，而是因为大多数人是从共享主机场景起步的，这导致几乎完全依赖于Apache的由.htaccess实现的分布式管理能力。

Nginx

Nginx因越来越多的用户采用其性能配置正获得越来越多的支持，但是在一些关键领域仍需赶超。

在过去，因为大多数的早期开发和文档都在俄罗斯，所以很难找到关于Nginx的综合性英文版文档。随着项目的发展兴致的提升，文档已经被添加完毕，且目前在Nginx网站和其他第三方平台上有大量的管理资源。

关于第三方应用程序，支持和文档正变得越来越容易获得，且在某些情况下，包维护者开始为Apache和Nginx的自动配置提供选择。即使没有支持，配置Nginx与可供选择的软件一同工作通常是直截了当的，只要项目自身无需记录其需要内容(如权限和头部信息等)。

Apache与Nginx配合使用

在了解了Apache和Nginx的优点与局限后，你将知道哪个服务器更适合你的需求。然而，许多用户发现可以结合二者各自的强项来共同使用。

一种普遍的结合配置是在Apache之前加入Nginx作为反向代理层。这将允许Nginx处理所有来自客户端的请求。这利用了Nginx的快速处理速度和同时处理大量连接的能力。

对于静态请求，Nginx擅长处理，所以文件将被快速提供并直接返回客户端。对于动态内容，比如PHP文件，Nginx将请求代理至Apache，然后Apache处理结果并返回渲染后页面。最后Nginx可以将内容返回给客户端。

这种设置适用于许多人，因为这过程中的Nginx被作为分拣机功能。它将处理所有请求并可以将它自身不具备处理能力的请求传递给他人来处理。通过减少对Apache服务器的请求处理，我们可以减轻一些由Apache进程或现线程占用导致的阻塞。

这种配置允许你根据需要来添加后台服务器进行扩展。Nginx可以轻松地将配置传递至服务器池，从而提高该配置对故障与性能的恢复能力。

结论

如你所见，Apache和Nginx都是很强大、灵活及功能丰富。确定使用哪个服务器最适合你，主要是评估你的特定需求以及使用你所想看到的模式进行测试。

这两个项目间存在对原始性能、功能性以及对每个解决方案的启动和运行所需要的实现时间产生非常实际的影响的差异。然而，这些通常是一系列不应被忽视的而最终权衡后的结果。最后，并不存在一个适合所有人的Web服务器，所以请使用最符合你目标的解决方案。

Vim基础命令整理

Fri, 21 Jun 2019 02:22:46 +0000

概述

本文按照使用类型对Vim进行分类整理。

正文

删除
- 单个字符
  
  x: 删除当前光标下的字符
  
  X: 删除当前光标前的字符
- 多个字符
  
  dw: 删除单词，从光标起始处至下个单词字母开头处，包括中间的所有空格
  
  D: 删除从光标起始处至行末
  
  dd: 删除当前行，并跳转至下一行首
- 换行符
  
  J: 删除当前行的换行符，并以空格拼接
移动
- 单个字符
  
  h: 向左移动
  
  j: 向下移动
  
  k: 向上移动
  
  l: 向右移动
- 单个词(连续的多个符号[,.:// …]算一个词)
  
  w: 向右移动至下个词首
  
  e: 向右移动至下个词末
  
  b: 向左移动至上个词首
- 大词(单个换行符、连续的空格或Tab)
  
  W: 向右移至下个词首
  
  B: 向左移至上个词首
- 行内跳转
  
  0: 光标移动至行首
  
  $: 光标移动至行末
  
  ^: 光标移动至行首(非空格)
- 页面跳转
  
  gg: 光标跳转至文件起始行首部
  
  G: 光标跳转至文件末行首部
  
  H: 光标跳转至当前页面起始行首部(非空格)
  
  M: 光标跳转至当前页面中间行首部(非空格)
  
  L: 光标跳转至当前页面末行首部(非空格)
  
  :$line_num: 光标跳转至输入的行号数
- 翻页 此处的^相当于Ctrl键
  
  ^U: 向上翻半页
  
  ^D: 向下翻半页
  
  ^B: 向上翻一页
  
  ^F: 向下翻一页
  
  ^E: 屏幕向上滚动一行
  
  ^Y: 屏幕向下滚动一行
插入

i: 光标前插入

a: 光标后插入

I: 行首部插入

A: 行末尾插入

o: 当前行下方另起一行插入

O: 当前行上方另起一行插入
替换

r: 选中当前光标下的单个字符，只能替换单个字符后并返回命令模式

R: 选中当前光标下的字符，替换单个字符后保持插入状态

s: 删除光标下的单个字符后保持插入状态

S: 删除当前行后保持插入状态

C: 删除当前行(光标后)，并保持输入状态

cw: 删除一个词，并保持输入状态(w可替换成其他命令，如：s、p等)
查找
- 全文
  
  /{string}: 查找所需字符串，并跳转至光标后的第一个匹配处
  
  *: 查找光标下的单词，并跳转至第一个匹配处
  
  n: 跳转至下一个匹配处
  
  N: 跳转至上一个匹配处
- 单行
  
  t{character}: 在当前行光标起始处开始查找匹配的字符，光标跳转至第一个匹配项前
  
  f{character}: 在当前行光标起始处后开始查找匹配的字符，光标跳转至第一个匹配项上
  
  ;: 跳转至下一个匹配项
  
  ,: 跳转至上一个匹配项，若为t查找结果则光标跳转至匹配项后
匹配替换

:s /{search_str}/{replace_str}/g: 在当前行查找匹配项并替换

:%s /{search_str}/{replace_str}/g: 全文查找匹配项并替换
复制粘贴
- 复制
  
  y: 复制已选文本区域
  
  yy: 复制当前行
- 粘贴
  
  p: 粘贴已选或刚删除的文本于光标后
  
  P: 粘贴已选或刚删除的文本于光标前
其他

u: 撤销上一次操作

Ctrl-r: 重新执行上一次操作

.: 重复上次操作，.前面可以带上数字表示重复次数

v: 进入视图模式，默认选中当前光标字符，支持单字符选择

V: 进入视图模式，默认选中当前行，支持行选择

MySQL 8.0 新特性--CTE介绍

Wed, 28 Nov 2018 06:55:46 +0000

原文地址：http://www.mysqltutorial.org/mysql-cte/

总结

在这篇文章中，你将学会如何使用MySQL的公用表表达式(CTE:common table expression)来构建更易阅读的复杂语句。

什么是公用表表结构(CTE)

CTE是一个以临时结果集命名的概念，它仅存在于单个SQL语句的执行范围内，如：SELECT、INSERT、UPDATE或者DELETE。

与派生表类似，一个CTE不作为存储对象，仅在执行期间持续存在。不同的是，CTE可以是自引用(递归CTE)，也可在同一个查询中被多次引用。除此之外，CTE提供了更好的可读性和性能。

CTE语法

一个CTE的结构包括名字，可选列名列表以及定义CTE的查询。定义完CTE后，您可以像声明SELECT、INSERT、UPDATE、DELETE或CREATE视图一样来使用它。

如下举例说明了CTE的基本语法：

WITH cte_name (column_list) AS (
    query
) 
SELECT * FROM cte_name;

清注意，在上面的query语句中的列数必须与column_list的数量一致。如果你忽略了column_list，CTE将使用CTE定义的query语句中的列列表。

简单的CTE例子

下面的例子说明了如何使用CTE从示例数据库中的customer表中查询所需数据。这个例子仅作为示范操作，目的是为了让您更好的理解CTE概念。

WITH customers_in_usa AS (
    SELECT 
        customerName, state
    FROM
        customers
    WHERE
        country = 'USA'
)
SELECT 
    customerName
FROM
    customers_in_usa
WHERE
    state = 'CA'
ORDER BY customerName;

查询结果：

在这个例子中，CTE的名称是customers_in_usa，查询语句返回customerName和state两个列。因此，该CTE返回位于美国的所有顾客。定义完customers_in_usa后，我们通过引用SELECT声明语句来获取位于California的所有顾客。

请看另一个例子：

WITH topsales2003 AS (
    SELECT 
        salesRepEmployeeNumber employeeNumber,
        SUM(quantityOrdered * priceEach) sales
    FROM
        orders
            INNER JOIN
        orderdetails USING (orderNumber)
            INNER JOIN
        customers USING (customerNumber)
    WHERE
        YEAR(shippedDate) = 2003
            AND status = 'Shipped'
    GROUP BY salesRepEmployeeNumber
    ORDER BY sales DESC
    LIMIT 5
)
SELECT 
    employeeNumber, firstName, lastName, sales
FROM
    employees
        JOIN
    topsales2003 USING (employeeNumber);

查询结果：

在这个例子中，CTE返回在2003年的前五名推销员。之后，我们引用该CTE(topsales2003)来获取关于这些推销员的额外信心，包括名字和姓氏。

一个更复杂的CTE例子

请看如下例子：

WITH salesrep AS (
    SELECT 
        employeeNumber,
        CONCAT(firstName, ' ', lastName) AS salesrepName
    FROM
        employees
    WHERE
        jobTitle = 'Sales Rep'
),
customer_salesrep AS (
    SELECT 
        customerName, salesrepName
    FROM
        customers
            INNER JOIN
        salesrep ON employeeNumber = salesrepEmployeeNumber
)
SELECT 
    *
FROM
    customer_salesrep
ORDER BY customerName;

查询结果：

在这个例子中，在同一个查询一句中我们有两个CTE。第一个CTE(salesrep)用于获取职位是推销员的雇员。第二个CTE(customer_salesrep)通过引用第一个CTE(salesrep)以及INNER JOIN分句来获取推销员以及他所负责的顾客。

在有了第二个CTE之后，我们可以使用简单的包含ORDER BY的SELECT语句来获取数据。

WITH分句的用法

有些上下文可以使用WITH分句来创建CTE：

可以用在SELECT、UPDATE以及DELETE语句的开头：

WITH ... SELECT ...
WITH ... UPDATE ...
WITH ... DELETE ...

可以用在子查询或者派生表子查询的开头：

SELECT ... WHERE id IN (WITH ... SELECT ...);
 
SELECT * FROM (WITH ... SELECT ...) AS derived_table;

可以用在包含SELECT子句的声明语句的SELECT之前

CREATE TABLE ... WITH ... SELECT ...
CREATE VIEW ... WITH ... SELECT ...
INSERT ... WITH ... SELECT ...
REPLACE ... WITH ... SELECT ...
DECLARE CURSOR ... WITH ... SELECT ...
EXPLAIN ... WITH ... SELECT ...

在这篇文章中，你已经学会了如何使用MySQL的公用表表达式。

Yusher's Blog

Solution:cannot load such file -- openssl (LoadError)

Solution:docker用户权限解决方案

秒杀产品的理解与应对

概述

特征

应对措施

扩展补充

MySQL-count语法使用与对比

概述

作用与区别

验证-数据表无null值或空值

验证-数据表存在null值或者空值

验证-name字段具有索引

MySQL Join的使用介绍

概述

表结构与数据

Join使用类型

内联接(INNER JOIN)

左连接(LEFT [OUTER] JOIN)

右连接(RIGHT [OUTER] JOIN)

差集(Intersect)

并集(UNION)

对称差(Semmetric Difference)

Apache vs Nginx(实际考虑因素对比)

引言

总体概述

Apache

Nginx

连接处理架构

Apache

Nginx

静态与动态内容对比

Apache

Nginx

分布式和集中式配置对比

Apache

Nginx

文件解析与基于URI解析的对比

Apache

Nginx

模块

Apache

Nginx

支持、兼容性、生态系统与文档

Apache

Nginx

Apache与Nginx配合使用

结论

Vim基础命令整理

概述

正文

MySQL 8.0 新特性--CTE介绍

总结

什么是公用表表结构(CTE)

CTE语法

简单的CTE例子

一个更复杂的CTE例子

WITH分句的用法

相关文章