wy471x

Nginx 源码阅读指南

2026-07-23T23:45:00+08:00

Nginx 源码阅读指南

一、读前准备

1.1 必备知识

C 语言：熟悉指针、函数指针、宏、位运算、结构体内存布局（offsetof）、变长参数
网络编程：TCP/IP、HTTP/1.1 协议、socket API（accept/recv/send/setsockopt）、非阻塞 I/O
操作系统：进程模型（fork）、信号（signal）、共享内存、epoll/kqueue 等多路复用机制
编译工具：能读懂 shell 脚本和 Makefile

1.2 环境搭建

# 编译带调试信息的 nginx
./auto/configure --with-debug --prefix=$(pwd)/build
make -j$(nproc)

# 用 GDB 调试
gdb ./objs/nginx
(gdb) b ngx_process_events_and_timers
(gdb) r

1.3 关键宏与惯例速查

宏/模式	含义
`NGX_OK` / `NGX_ERROR` / `NGX_AGAIN` / `NGX_DECLINED` / `NGX_DONE` / `NGX_BUSY` / `NGX_ABORT`	标准返回值，分别对应 0/-1/-2/-5/-4/-3/-6
`ngx_string("foo")`	编译期从字面量构造 `ngx_str_t`
`ngx_queue_data(q, type, link)`	从侵入式队列节点反查包含它的结构体
`ngx_rbtree_data(node, type, link)`	同上，针对红黑树节点
`ngx_log_debug` / `ngx_log_error`	分级日志宏，带 `--with-debug` 才会输出 debug 级别
`offsetof(type, member)`	计算成员在结构体中的偏移量，侵入式数据结构的基石

二、推荐阅读路线

第 0 步：理解构建系统（30 分钟）

从 auto/ 目录开始，不必细读每个脚本，重点是理解流程：

auto/configure — 入口，顺序调用 auto/options、auto/init、auto/cc/*、auto/os/*、auto/feature、auto/modules、auto/sources、auto/make
auto/modules — 最关键的文件之一。它决定哪些模块被编译进 ngx_modules[] 数组，模块的排列顺序决定了初始化顺序和处理优先级，不可随意改动
auto/sources — 定义了所有源文件列表的 shell 变量（CORE_SRCS、HTTP_SRCS 等），最终输出到 objs/Makefile

构建产物：

objs/ngx_auto_config.h — 所有 #define 宏（编译特性开关）
objs/ngx_modules.c — 自动生成的 ngx_modules[] 和 ngx_module_names[]

第 1 步：核心数据结构（2-3 小时）

这是最重要的基础，务必吃透。 按依赖关系建议顺序：

ngx_str_t  →  ngx_pool_t  →  ngx_array_t  →  ngx_list_t  →  ngx_queue_t  →  ngx_buf_t / ngx_chain_t  →  ngx_rbtree_t

逐个阅读文件：

阅读文件	重点理解
`src/core/ngx_string.h`	`ngx_str_t` 不是 C 字符串，`len` + `data` 二元组；`ngx_vslprintf` 等格式化函数
`src/core/ngx_palloc.h` + `ngx_palloc.c`	池分配器：小块从池中切，大块走 malloc；`ngx_palloc` vs `ngx_pnalloc`（对齐 vs 不对齐）；cleanup 回调机制
`src/core/ngx_array.h`	动态数组，元素连续存储，`ngx_array_push` 返回新元素的指针
`src/core/ngx_list.h`	链表+数组的混合体，每个 `part` 存放 `nalloc` 个元素
`src/core/ngx_queue.h`	纯粹的宏，侵入式双向循环链表，核心宏 `ngx_queue_data` 用 `offsetof` 反查容器
`src/core/ngx_buf.h` + `ngx_buf.c`	`ngx_buf_t` 统一了内存数据和文件数据；`ngx_chain_t` 构成数据流水线
`src/core/ngx_rbtree.h` + `ngx_rbtree.c`	红黑树，哨兵节点代替 NULL，自定义插入函数，`ngx_rbtree_data` 反查容器

第 2 步：进程模型与事件循环（2-3 小时）

这是理解 nginx 运行时行为的核心。

阅读顺序：

src/os/unix/ngx_process_cycle.c — main() 之后的真正入口
- ngx_master_process_cycle() — master 进程循环（信号处理、worker 管理）
- ngx_single_process_cycle() — 单进程模式（调试用）
- ngx_worker_process_cycle() — worker 进程的主循环（最关键的阅读目标）
- ngx_start_worker_processes() — 如何 fork worker
- 重点关注：热更新（HUP 信号）时新旧 worker 的切换逻辑

src/event/ngx_event.c — 事件子系统核心

ngx_event_process_init() — worker 启动时的事件初始化（创建连接池、事件池）

ngx_process_events_and_timers() — 事件循环的心脏，每次循环执行四个步骤：

① ngx_event_find_timer()       -- 从红黑树找出最近到期的定时器
② ngx_process_events()         -- 调用 epoll_wait / kqueue 等
③ ngx_event_expire_timers()    -- 处理到期定时器
④ ngx_event_process_posted()   -- 处理延迟执行的 posted 事件

src/event/ngx_event_timer.h — 定时器管理
- 全局红黑树 ngx_event_timer_rbtree，键值为 到期时间 = ngx_current_msec + delay
- 惰性延迟优化：阈值 300ms，避免频繁更新红黑树
src/event/ngx_event_posted.h — 延迟事件机制
- 三个全局队列：ngx_posted_accept_events、ngx_posted_events、ngx_posted_next_events
- 用于避免重入和批量化处理

第 3 步：连接管理（1-2 小时）

src/core/ngx_connection.h — 两个核心结构体
- ngx_connection_t：每条连接一个实例，包含 fd、读写事件、I/O 函数指针（被 SSL/QUIC 替换）、状态位
- ngx_listening_t：每个监听 socket 一个实例，包含接受回调、SSL/QUIC 标记
src/core/ngx_connection.c
- ngx_open_listening_sockets() — 打开所有监听端口
- ngx_get_connection() — 从预分配数组中取空闲连接
- ngx_close_connection() — 归还连接到空闲列表
src/event/ngx_event_accept.c
- ngx_event_accept() — accept 处理器，accept 互斥锁逻辑

关键设计：instance 位解决 stale event 问题

每次连接复用时，instance 位翻转。
当 epoll/kqueue 返回一个过时的事件时，
通过比对 instance 位发现不匹配 → 丢弃该事件。
这避免了额外系统调用来验证事件有效性。

第 4 步：配置系统（2 小时）

nginx 的配置解析器是一个递归下降解析器，是整个模块系统运转的基础。

src/core/ngx_conf_file.h — 核心类型
- ngx_command_t：每个配置指令的定义（名称、参数规则、set 函数、偏移量）
- ngx_conf_t：解析上下文
src/core/ngx_conf_file.c
- ngx_conf_parse() — 递归解析入口，遇到 block 指令会递归调用自身
- ngx_conf_handler() — 分发到模块的 set 函数

参数类型标志速查：

NGX_CONF_NOARGS         -- 无参数（如 "accept_mutex off;" 中的 off 是 flag，不是参数）
NGX_CONF_TAKE1~7        -- 正好 N 个参数
NGX_CONF_TAKE12         -- 1 或 2 个参数
NGX_CONF_FLAG           -- 布尔值（on/off）
NGX_CONF_BLOCK          -- 后面跟着 {} 块
NGX_CONF_1MORE          -- 至少 1 个参数

Setter 函数族：ngx_conf_set_flag_slot、ngx_conf_set_str_slot、ngx_conf_set_num_slot、ngx_conf_set_size_slot、ngx_conf_set_msec_slot 等，这些是配置解析的基础组件。

配置合并宏：

ngx_conf_merge_value(conf, prev, default)   // 数值：当前 → 父级 → 默认
ngx_conf_merge_str_value(conf, prev, default)
ngx_conf_merge_msec_value(conf, prev, default)

体现了 nginx 配置继承的三级 fallback 机制。

第 5 步：模块系统（1-2 小时）

src/core/ngx_module.h — ngx_module_t 结构体
- 全局索引 index 和类型内索引 ctx_index
- 类型特定的 ctx 指针
- commands 数组（配置指令定义）
- 生命周期钩子：init_master → init_module → init_process → exit_process → exit_master

模块类型：

NGX_CORE_MODULE    -- 核心模块（如 ngx_core_module、ngx_events_module、ngx_http_module）
NGX_EVENT_MODULE   -- 事件模块（如 ngx_epoll_module、ngx_kqueue_module）
NGX_HTTP_MODULE    -- HTTP 模块
NGX_MAIL_MODULE    -- Mail 模块
NGX_STREAM_MODULE  -- Stream 模块

src/core/ngx_module.c
- ngx_cycle_modules() — 复制模块数组到 cycle
- ngx_init_modules() — 调用每个模块的 init_module

HTTP 模块的特殊上下文 ngx_http_module_t：

typedef struct {
    ngx_int_t   (*preconfiguration)(ngx_conf_t *cf);
    ngx_int_t   (*postconfiguration)(ngx_conf_t *cf);
    void       *(*create_main_conf)(ngx_conf_t *cf);
    char       *(*init_main_conf)(ngx_conf_t *cf, void *conf);
    void       *(*create_srv_conf)(ngx_conf_t *cf);
    char       *(*merge_srv_conf)(ngx_conf_t *cf, void *prev, void *conf);
    void       *(*create_loc_conf)(ngx_conf_t *cf);
    char       *(*merge_loc_conf)(ngx_conf_t *cf, void *prev, void *conf);
} ngx_http_module_t;

这是理解 HTTP 模块如何工作的关键：main → srv → loc 三级配置的创建和合并都在这里。

第 6 步：HTTP 请求处理全链路（4-5 小时）⭐ 核心

这是 nginx 源码中最重要、最复杂的部分，建议反复阅读。

6.1 HTTP 框架初始化

src/http/ngx_http.c

ngx_http_block() — http {} 块的解析函数
- 创建 main/srv/loc 三级配置
- 初始化 phase engine（阶段引擎）
- 调用各模块的 postconfiguration（此时注册 handler、filter）
- 初始化请求头解析表、变量系统

6.2 11 个处理阶段

src/http/ngx_http_core_module.h

NGX_HTTP_POST_READ_PHASE       -- 读完请求头之后（realip 模块在此）
NGX_HTTP_SERVER_REWRITE_PHASE  -- server 级别的 rewrite
NGX_HTTP_FIND_CONFIG_PHASE     -- 匹配 location
NGX_HTTP_REWRITE_PHASE         -- location 级别的 rewrite
NGX_HTTP_POST_REWRITE_PHASE    -- rewrite 之后（检查重定向循环）
NGX_HTTP_PREACCESS_PHASE       -- 访问限制（limit_conn、limit_req）
NGX_HTTP_ACCESS_PHASE          -- 权限检查（allow/deny、auth_basic、auth_request）
NGX_HTTP_POST_ACCESS_PHASE     -- access 之后（处理 satisfy all/any）
NGX_HTTP_PRECONTENT_PHASE      -- 内容产生之前（mirror、try_files）
NGX_HTTP_CONTENT_PHASE         -- 产生响应内容（proxy_pass、fastcgi_pass、static）
NGX_HTTP_LOG_PHASE             -- 记录日志（请求处理完成之后）

每个阶段由 checker 函数 驱动，依次调用注册到该阶段的 handler。关键 checker：

Checker	阶段	行为
`ngx_http_core_generic_phase`	rewrite 等	顺序执行，DECLINED 则下一个
`ngx_http_core_find_config_phase`	find_config	匹配 location，只执行一次
`ngx_http_core_access_phase`	access	支持 satisfy all/any
`ngx_http_core_content_phase`	content	找到第一个返回 OK 的 handler

阅读入口：ngx_http_core_run_phases()

6.3 请求生命周期

src/http/ngx_http_request.h — ngx_http_request_t 结构体（很大，约 60+ 字段）

src/http/ngx_http_request.c — 按顺序阅读以下函数：

新连接到达：
  ngx_http_init_connection()
    → ngx_http_wait_request_handler()      -- 等待完整的请求头到达

请求头解析完成：
  ngx_http_process_request_line()
    → ngx_http_process_request_headers()
      → ngx_http_process_request()
        → ngx_http_process_request_headers()  -- 解析 Host、Content-Length 等
        → ngx_http_handler()                  -- 设置 r->phase_handler = 0
          → ngx_http_core_run_phases(r)       -- 驱动阶段引擎

响应发送：
  ngx_http_writer()                         -- 异步发送响应体

请求结束：
  ngx_http_finalize_request()
    → ngx_http_free_request()
      → ngx_destroy_pool(r->pool)          -- 销毁请求内存池

6.4 过滤器链

nginx 的输出不是由单个模块一次性完成的，而是通过过滤器链（责任链模式）协作产生的。

头过滤器链：

ngx_http_top_header_filter
  → ngx_http_not_modified_header_filter
  → ...
  → ngx_http_gzip_header_filter
  → ...
  → ngx_http_header_filter          -- 最终序列化 HTTP 头为字节流

体过滤器链：

ngx_http_top_body_filter
  → ngx_http_range_body_filter
  → ngx_http_copy_filter            -- 必要时将 in_file buf 复制到内存
  → ngx_http_gzip_body_filter
  → ngx_http_chunked_body_filter
  → ngx_http_write_filter           -- 最终调用 c->send_chain() 发送

过滤器注册模式：

// 在 postconfiguration 中注册：
static ngx_int_t
ngx_http_my_init(ngx_conf_t *cf)
{
    ngx_http_next_header_filter  = ngx_http_top_header_filter;
    ngx_http_top_header_filter   = ngx_http_my_header_filter;

    ngx_http_next_body_filter    = ngx_http_top_body_filter;
    ngx_http_top_body_filter     = ngx_http_my_body_filter;

    return NGX_OK;
}

注意：后注册的先执行（因为每次插在链头）。

6.5 Location 匹配

src/http/ngx_http_core_module.c

ngx_http_core_find_config_phase() 中的匹配算法：

用 ngx_hash_lookup() 在 locations 哈希表中做前缀匹配
如果匹配到的 location 有嵌套，递归查找
最后用 regex_locations 队列做正则匹配（优先级最高，使用 =~ 或 ~*）

配置合并的路径：匹配到某个 location 后，其 loc_conf[module_index] 已在解析阶段通过 merge_loc_conf 正确地继承自 server 和 main 级别的配置。

6.6 Upstream 机制

src/http/ngx_http_upstream.h + src/http/ngx_http_upstream.c

upstream 的状态机：

ngx_http_upstream_init()
  → ngx_http_upstream_connect()           -- 建立到后端的连接
    → ngx_http_upstream_send_request()    -- 发送请求体
      → ngx_http_upstream_process_header()  -- 解析响应头
        → ngx_http_upstream_process_body_in_memory() 或 sendfile/pipe -- 转发响应体
          → ngx_http_upstream_finalize_request()

负载均衡是可插拔的，通过 ngx_http_upstream_peer_t 接口：

ngx_http_upstream_round_robin.c — 加权轮询（默认）
ngx_http_upstream_hash_module.c — 一致性哈希
ngx_http_upstream_least_conn_module.c — 最小连接数
ngx_http_upstream_random_module.c — 随机选择

第 7 步：补充阅读（按需）

日志系统：src/core/ngx_log.h + ngx_log.c — ngx_log_t 分级日志，链式日志对象
变量系统：src/http/ngx_http_variables.c — $remote_addr、$host 等变量如何注册和求值
正则引擎：src/core/ngx_regex.c — 对 PCRE 的封装（nginx 自己不做正则引擎）
共享内存与 Slab 分配器：src/core/ngx_slab.c — 用于多进程共享数据的 slab 分配器
SSL/TLS：src/event/ngx_event_openssl.c — 如何通过替换 c->recv/send 函数指针实现 SSL
HTTP/2：src/http/v2/ — HTTP/2 帧的解析和多路复用
QUIC/HTTP/3：src/event/quic/ + src/http/v3/ — QUIC 传输层和 HTTP/3 的实现

三、贯穿始终的设计模式与思维方式

3.1 侵入式数据结构

nginx 不单独分配链表节点或树节点，而是将 ngx_queue_t 和 ngx_rbtree_node_t 直接嵌入在使用它们的结构体中。零额外分配，极致效率。

// 不是：list<Item*> items（每次插入要 malloc 一个节点）
// 而是：Item 里包含 ngx_queue_t queue，直接链入

3.2 预分配 + 重用

连接、事件、内存池——在启动时预分配好，运行时不再 malloc。nginx 的哲学是：“我能在启动时算清楚的最大资源量，就预分配好”。

3.3 I/O 函数指针的多态

c->recv = ngx_ssl_recv;   // SSL 模块偷偷换了
c->send = ngx_ssl_send;

高层代码（HTTP 框架）完全不感知底层是 TCP 还是 SSL 还是 QUIC，这是 nginx 实现协议升级和 SSL 透明的关键手段。

3.4 返回值驱动的控制流

nginx 不使用异常或 goto，而是通过返回值表达控制意图：

返回值	语义
`NGX_OK`	完成，调用者继续
`NGX_ERROR`	出错，终止
`NGX_AGAIN`	资源不足（缓冲满了、数据未到），暂停等待下次事件触发
`NGX_DECLINED`	我不处理，找下一个（handler 单链表遍历的核心）
`NGX_DONE`	已处理，但请求未结束（异步操作 pending）
`NGX_BUSY`	忙，稍后再试

理解 NGX_AGAIN 和 NGX_DECLINED 的区别特别重要——前者是”等一会儿我重试”，后者是”换下一个”。

3.5 优雅的零停机

配置重载（nginx -s reload）的核心逻辑：

Master 收到 SIGHUP → 创建新 ngx_cycle_t，fork 新 worker
旧 worker 收到 SIGQUIT → 优雅关闭（处理完现有连接再退出）
新旧 worker 短暂共存，旧 worker 关闭后新 cycle 接管

这依赖于 cycle->old_cycle 的设计：新 cycle 持有旧 cycle 引用，等旧 worker 退出后释放。

四、调试技巧

4.1 Debug 日志

编译时带 --with-debug，然后在配置中设置：

error_log /var/log/nginx/debug.log debug;

4.2 GDB 常用断点

# 事件循环入口
b ngx_process_events_and_timers

# 请求处理入口
b ngx_http_process_request

# 阶段引擎
b ngx_http_core_run_phases

# 连接分配
b ngx_get_connection

# upstream 连接
b ngx_http_upstream_connect

# 一个连接上的所有 recv/send 调用
b ngx_unix_recv
b ngx_unix_send

4.3 打印 ngx_str_t

# ngx_str_t 不是 C 字符串，在 GDB 中需要自定义打印
define print_ngx_str
  set $s = (ngx_str_t*)$arg0
  printf "%.*s\n", $s->len, $s->data
end

4.4 追踪内存分配

在 src/core/ngx_palloc.c 的关键函数打断点：

ngx_create_pool — 池创建
ngx_palloc — 小块分配
ngx_palloc_block — 分配新池块
ngx_pfree — 大块释放
ngx_destroy_pool — 池销毁

五、建议的阅读实践

不要试图按文件序号从头读到尾。nginx 的静态函数和全局变量很多，按头文件依赖关系去读。
每次只追踪一个功能链路。比如 “一个 HTTP GET 请求从接收到返回的完整路径”，只关注这条线上的函数，忽略旁路。
画图。nginx 源码中的结构体嵌套很深，手绘以下关系图会很有帮助：
- ngx_cycle_t → conf_ctx → 各模块配置的索引关系
- ngx_connection_t → read / write → ngx_event_t → handler 的调用链
- HTTP 阶段引擎中 checker → handler → next 的跳转关系
- 过滤器链中 ngx_http_top_header_filter → next → … 的顺序
从简单的第三方模块入手。阅读 src/http/modules/ngx_http_echo_module.c 级别的简单模块，理解 handler 和 filter 怎么写。
对比阅读。在 src/http/modules/ 下找两个类似功能的模块对比（如 proxy vs fastcgi），理解差异在哪里。
重复读核心函数。ngx_process_events_and_timers()、ngx_http_core_run_phases()、ngx_conf_parse()、ngx_http_upstream_connect() 这几个函数值得反复读，每次都会发现新细节。

六、核心文件索引

文件	阅读优先级	核心内容
`src/core/nginx.c`	★★★	`main()` 入口
`src/core/ngx_cycle.c`	★★★	`ngx_init_cycle()` 循环初始化
`src/core/ngx_palloc.c`	★★★	内存池实现
`src/core/ngx_buf.c`	★★★	buffer 和 chain 操作
`src/core/ngx_connection.c`	★★★	连接预分配和管理
`src/core/ngx_conf_file.c`	★★★	配置解析器
`src/core/ngx_module.c`	★★★	模块加载和初始化
`src/core/ngx_string.c`	★★☆	字符串工具函数集
`src/core/ngx_array.h`	★★★	动态数组
`src/core/ngx_list.h`	★★★	链表+数组混合
`src/core/ngx_queue.h`	★★★	侵入式双向链表
`src/core/ngx_rbtree.c`	★★☆	红黑树
`src/core/ngx_hash.c`	★★☆	静态哈希表
`src/core/ngx_log.c`	★★☆	日志系统
`src/os/unix/ngx_process_cycle.c`	★★★	master/worker 进程管理
`src/event/ngx_event.c`	★★★	事件循环核心
`src/event/ngx_event_accept.c`	★★☆	accept 与惊群处理
`src/event/ngx_event_timer.h`	★★☆	定时器管理
`src/event/modules/ngx_epoll_module.c`	★★☆	epoll 事件模块
`src/http/ngx_http.c`	★★★	HTTP 框架初始化
`src/http/ngx_http_request.c`	★★★	请求生命周期
`src/http/ngx_http_core_module.c`	★★★	核心指令、phase checker
`src/http/ngx_http_upstream.c`	★★★	upstream 代理机制
`src/http/ngx_http_variables.c`	★★☆	变量系统
`src/http/ngx_http_header_filter.c`	★★☆	响应头序列化
`src/http/ngx_http_write_filter.c`	★★☆	最终发送到 socket
`src/http/modules/ngx_http_proxy_module.c`	★★☆	典型 HTTP 代理模块
`src/http/modules/ngx_http_static_module.c`	★☆☆	最简单的 content handler

最后建议：读 nginx 源码是一场马拉松，不是短跑。核心代码大约 10 万行，但设计高度一致，一旦掌握了前 30% 的模式，剩下的 70% 会提速很快。祝阅读顺利。

Nginx Source Code Reading Guide

2026-07-23T23:45:00+08:00

Nginx Source Code Reading Guide

1. Preparation

1.1 Prerequisites

C Language: pointers, function pointers, macros, bitwise operations, struct memory layout (offsetof), variadic arguments
Network Programming: TCP/IP, HTTP/1.1 protocol, socket API (accept/recv/send/setsockopt), non-blocking I/O
Operating Systems: process model (fork), signals, shared memory, epoll/kqueue multiplexing mechanisms
Build Tools: ability to read shell scripts and Makefiles

1.2 Environment Setup

# Build nginx with debug info
./auto/configure --with-debug --prefix=$(pwd)/build
make -j$(nproc)

# Debug with GDB
gdb ./objs/nginx
(gdb) b ngx_process_events_and_timers
(gdb) r

1.3 Key Macros and Conventions Quick Reference

Macro/Pattern	Meaning
`NGX_OK` / `NGX_ERROR` / `NGX_AGAIN` / `NGX_DECLINED` / `NGX_DONE` / `NGX_BUSY` / `NGX_ABORT`	Standard return values: 0/-1/-2/-5/-4/-3/-6
`ngx_string("foo")`	Compile-time construction of `ngx_str_t` from a literal
`ngx_queue_data(q, type, link)`	Retrieve the containing struct from an intrusive queue node
`ngx_rbtree_data(node, type, link)`	Same as above, for rbtree nodes
`ngx_log_debug` / `ngx_log_error`	Leveled logging macros; debug level only output with `--with-debug`
`offsetof(type, member)`	Calculate the offset of a member within a struct — the cornerstone of intrusive data structures

2. Recommended Reading Roadmap

Step 0: Understand the Build System (30 min)

Start from the auto/ directory. No need to read every script in detail — focus on understanding the flow:

auto/configure — Entry point, sequentially calls auto/options, auto/init, auto/cc/*, auto/os/*, auto/feature, auto/modules, auto/sources, auto/make
auto/modules — One of the most critical files. It determines which modules are compiled into the ngx_modules[] array. The ordering of modules determines initialization order and processing priority — never change it casually
auto/sources — Defines shell variables listing all source files (CORE_SRCS, HTTP_SRCS, etc.), ultimately output to objs/Makefile

Build artifacts:

objs/ngx_auto_config.h — All #define macros (compile-time feature switches)
objs/ngx_modules.c — Auto-generated ngx_modules[] and ngx_module_names[]

Step 1: Core Data Structures (2-3 hours)

This is the most important foundation — master it thoroughly. Suggested order by dependency:

ngx_str_t  →  ngx_pool_t  →  ngx_array_t  →  ngx_list_t  →  ngx_queue_t  →  ngx_buf_t / ngx_chain_t  →  ngx_rbtree_t

Read file by file:

File	Key Focus
`src/core/ngx_string.h`	`ngx_str_t` is not a C string — it’s a `len` + `data` pair; `ngx_vslprintf` and other formatting functions
`src/core/ngx_palloc.h` + `ngx_palloc.c`	Pool allocator: small blocks carved from pool, large blocks via malloc; `ngx_palloc` vs `ngx_pnalloc` (aligned vs unaligned); cleanup callback mechanism
`src/core/ngx_array.h`	Dynamic array, elements stored contiguously; `ngx_array_push` returns a pointer to the new element
`src/core/ngx_list.h`	Hybrid of linked list + array; each `part` holds `nalloc` elements
`src/core/ngx_queue.h`	Pure macros, intrusive doubly-linked circular list; the core macro `ngx_queue_data` uses `offsetof` to retrieve the container
`src/core/ngx_buf.h` + `ngx_buf.c`	`ngx_buf_t` unifies memory data and file data; `ngx_chain_t` forms a data pipeline
`src/core/ngx_rbtree.h` + `ngx_rbtree.c`	Red-black tree, sentinel node instead of NULL, custom insert function; `ngx_rbtree_data` retrieves the container

Step 2: Process Model and Event Loop (2-3 hours)

This is the core of understanding nginx runtime behavior.

Reading order:

src/os/unix/ngx_process_cycle.c — The real entry point after main()
- ngx_master_process_cycle() — Master process loop (signal handling, worker management)
- ngx_single_process_cycle() — Single process mode (for debugging)
- ngx_worker_process_cycle() — The main loop of a worker process (most critical reading target)
- ngx_start_worker_processes() — How workers are forked
- Key focus: the switching logic between old and new workers during hot reload (HUP signal)

src/event/ngx_event.c — Event subsystem core

ngx_event_process_init() — Event initialization when a worker starts (creates connection pool, event pool)

ngx_process_events_and_timers() — The heart of the event loop, four steps per iteration:

① ngx_event_find_timer()       -- Find the soonest-expiring timer from the rbtree
② ngx_process_events()         -- Call epoll_wait / kqueue etc.
③ ngx_event_expire_timers()    -- Process expired timers
④ ngx_event_process_posted()   -- Process deferred posted events

src/event/ngx_event_timer.h — Timer management
- Global rbtree ngx_event_timer_rbtree, keyed by expiry = ngx_current_msec + delay
- Lazy delay optimization: 300ms threshold to avoid frequent rbtree updates
src/event/ngx_event_posted.h — Deferred event mechanism
- Three global queues: ngx_posted_accept_events, ngx_posted_events, ngx_posted_next_events
- Used to avoid reentrancy and enable batch processing

Step 3: Connection Management (1-2 hours)

src/core/ngx_connection.h — Two core structs
- ngx_connection_t: One instance per connection, contains fd, read/write events, I/O function pointers (swapped by SSL/QUIC), status bits
- ngx_listening_t: One instance per listening socket, contains accept callback, SSL/QUIC flags
src/core/ngx_connection.c
- ngx_open_listening_sockets() — Open all listening ports
- ngx_get_connection() — Get a free connection from the pre-allocated array
- ngx_close_connection() — Return a connection to the free list
src/event/ngx_event_accept.c
- ngx_event_accept() — Accept handler, accept mutex logic

Key design: instance bit solves the stale event problem

Every time a connection is reused, the instance bit flips.
When epoll/kqueue returns a stale event,
the instance bit mismatch is detected → the event is discarded.
This avoids extra syscalls to verify event validity.

Step 4: Configuration System (2 hours)

nginx’s configuration parser is a recursive descent parser — the foundation upon which the entire module system operates.

src/core/ngx_conf_file.h — Core types
- ngx_command_t: Definition of each configuration directive (name, argument rules, set function, offset)
- ngx_conf_t: Parse context
src/core/ngx_conf_file.c
- ngx_conf_parse() — Recursive parse entry point; calls itself recursively for block directives
- ngx_conf_handler() — Dispatches to a module’s set function

Argument type flags quick reference:

NGX_CONF_NOARGS         -- No arguments (e.g., "off" in "accept_mutex off;" is a flag, not an argument)
NGX_CONF_TAKE1~7        -- Exactly N arguments
NGX_CONF_TAKE12         -- 1 or 2 arguments
NGX_CONF_FLAG           -- Boolean (on/off)
NGX_CONF_BLOCK          -- Followed by a {} block
NGX_CONF_1MORE          -- At least 1 argument

Setter function family: ngx_conf_set_flag_slot, ngx_conf_set_str_slot, ngx_conf_set_num_slot, ngx_conf_set_size_slot, ngx_conf_set_msec_slot, etc. — the basic building blocks of configuration parsing.

Configuration merge macros:

ngx_conf_merge_value(conf, prev, default)   // Numeric: current → parent → default
ngx_conf_merge_str_value(conf, prev, default)
ngx_conf_merge_msec_value(conf, prev, default)

These embody nginx’s three-level fallback mechanism for configuration inheritance.

Step 5: Module System (1-2 hours)

src/core/ngx_module.h — The ngx_module_t struct
- Global index index and type-specific index ctx_index
- Type-specific ctx pointer
- commands array (configuration directive definitions)
- Lifecycle hooks: init_master → init_module → init_process → exit_process → exit_master

Module types:

NGX_CORE_MODULE    -- Core modules (e.g., ngx_core_module, ngx_events_module, ngx_http_module)
NGX_EVENT_MODULE   -- Event modules (e.g., ngx_epoll_module, ngx_kqueue_module)
NGX_HTTP_MODULE    -- HTTP modules
NGX_MAIL_MODULE    -- Mail modules
NGX_STREAM_MODULE  -- Stream modules

src/core/ngx_module.c
- ngx_cycle_modules() — Copy the module array into the cycle
- ngx_init_modules() — Call each module’s init_module

HTTP module-specific context ngx_http_module_t:

typedef struct {
    ngx_int_t   (*preconfiguration)(ngx_conf_t *cf);
    ngx_int_t   (*postconfiguration)(ngx_conf_t *cf);
    void       *(*create_main_conf)(ngx_conf_t *cf);
    char       *(*init_main_conf)(ngx_conf_t *cf, void *conf);
    void       *(*create_srv_conf)(ngx_conf_t *cf);
    char       *(*merge_srv_conf)(ngx_conf_t *cf, void *prev, void *conf);
    void       *(*create_loc_conf)(ngx_conf_t *cf);
    char       *(*merge_loc_conf)(ngx_conf_t *cf, void *prev, void *conf);
} ngx_http_module_t;

This is key to understanding how HTTP modules work: the creation and merging of main → srv → loc three-level configurations all happen here.

Step 6: HTTP Request Processing Pipeline (4-5 hours) ⭐ Core

This is the most important and complex part of the nginx source code — read it repeatedly.

6.1 HTTP Framework Initialization

src/http/ngx_http.c

ngx_http_block() — The parse function for the http {} block
- Creates main/srv/loc three-level configurations
- Initializes the phase engine
- Calls each module’s postconfiguration (handlers and filters are registered here)
- Initializes request header parsing tables and the variable system

6.2 The 11 Processing Phases

src/http/ngx_http_core_module.h

NGX_HTTP_POST_READ_PHASE       -- After reading request headers (realip module lives here)
NGX_HTTP_SERVER_REWRITE_PHASE  -- Server-level rewrite
NGX_HTTP_FIND_CONFIG_PHASE     -- Location matching
NGX_HTTP_REWRITE_PHASE         -- Location-level rewrite
NGX_HTTP_POST_REWRITE_PHASE    -- After rewrite (checks for redirect loops)
NGX_HTTP_PREACCESS_PHASE       -- Access limits (limit_conn, limit_req)
NGX_HTTP_ACCESS_PHASE          -- Authorization checks (allow/deny, auth_basic, auth_request)
NGX_HTTP_POST_ACCESS_PHASE     -- After access (handles satisfy all/any)
NGX_HTTP_PRECONTENT_PHASE      -- Before content generation (mirror, try_files)
NGX_HTTP_CONTENT_PHASE         -- Generate response content (proxy_pass, fastcgi_pass, static)
NGX_HTTP_LOG_PHASE             -- Logging (after request processing is complete)

Each phase is driven by a checker function that sequentially invokes the handlers registered for that phase. Key checkers:

Checker	Phase	Behavior
`ngx_http_core_generic_phase`	rewrite, etc.	Sequential execution, DECLINED → next handler
`ngx_http_core_find_config_phase`	find_config	Match location, executes only once
`ngx_http_core_access_phase`	access	Supports satisfy all/any
`ngx_http_core_content_phase`	content	Finds the first handler that returns OK

Reading entry point: ngx_http_core_run_phases()

6.3 Request Lifecycle

src/http/ngx_http_request.h — ngx_http_request_t struct (very large, ~60+ fields)

src/http/ngx_http_request.c — Read the following functions in order:

New connection arrives:
  ngx_http_init_connection()
    → ngx_http_wait_request_handler()      -- Wait for the complete request header to arrive

Request header parsed:
  ngx_http_process_request_line()
    → ngx_http_process_request_headers()
      → ngx_http_process_request()
        → ngx_http_process_request_headers()  -- Parse Host, Content-Length, etc.
        → ngx_http_handler()                  -- Set r->phase_handler = 0
          → ngx_http_core_run_phases(r)       -- Drive the phase engine

Response sending:
  ngx_http_writer()                         -- Asynchronously send the response body

Request finished:
  ngx_http_finalize_request()
    → ngx_http_free_request()
      → ngx_destroy_pool(r->pool)          -- Destroy the request memory pool

6.4 Filter Chain

nginx output is not produced by a single module in one shot — it is collaboratively generated through a filter chain (Chain of Responsibility pattern).

Header filter chain:

ngx_http_top_header_filter
  → ngx_http_not_modified_header_filter
  → ...
  → ngx_http_gzip_header_filter
  → ...
  → ngx_http_header_filter          -- Ultimately serializes HTTP headers into a byte stream

Body filter chain:

ngx_http_top_body_filter
  → ngx_http_range_body_filter
  → ngx_http_copy_filter            -- Copies in_file bufs to memory when necessary
  → ngx_http_gzip_body_filter
  → ngx_http_chunked_body_filter
  → ngx_http_write_filter           -- Ultimately calls c->send_chain() to send

Filter registration pattern:

// Register in postconfiguration:
static ngx_int_t
ngx_http_my_init(ngx_conf_t *cf)
{
    ngx_http_next_header_filter  = ngx_http_top_header_filter;
    ngx_http_top_header_filter   = ngx_http_my_header_filter;

    ngx_http_next_body_filter    = ngx_http_top_body_filter;
    ngx_http_top_body_filter     = ngx_http_my_body_filter;

    return NGX_OK;
}

Note: the last registered executes first (because each is inserted at the head of the chain).

6.5 Location Matching

src/http/ngx_http_core_module.c

The matching algorithm in ngx_http_core_find_config_phase():

Use ngx_hash_lookup() on the locations hash table for prefix matching
If the matched location has nested locations, search recursively
Finally, use the regex_locations queue for regex matching (highest priority, using =~ or ~*)

Configuration merge path: after matching a location, its loc_conf[module_index] has already correctly inherited from server and main level configurations via merge_loc_conf during the parsing phase.

6.6 Upstream Mechanism

src/http/ngx_http_upstream.h + src/http/ngx_http_upstream.c

The upstream state machine:

ngx_http_upstream_init()
  → ngx_http_upstream_connect()           -- Establish connection to backend
    → ngx_http_upstream_send_request()    -- Send request body
      → ngx_http_upstream_process_header()  -- Parse response header
        → ngx_http_upstream_process_body_in_memory() or sendfile/pipe -- Forward response body
          → ngx_http_upstream_finalize_request()

Load balancing is pluggable via the ngx_http_upstream_peer_t interface:

ngx_http_upstream_round_robin.c — Weighted round-robin (default)
ngx_http_upstream_hash_module.c — Consistent hashing
ngx_http_upstream_least_conn_module.c — Least connections
ngx_http_upstream_random_module.c — Random selection

Step 7: Supplementary Reading (as needed)

Logging System: src/core/ngx_log.h + ngx_log.c — ngx_log_t leveled logging, chained log objects
Variable System: src/http/ngx_http_variables.c — How variables like $remote_addr, $host are registered and evaluated
Regex Engine: src/core/ngx_regex.c — Wrapper around PCRE (nginx does not implement its own regex engine)
Shared Memory & Slab Allocator: src/core/ngx_slab.c — Slab allocator for multi-process shared data
SSL/TLS: src/event/ngx_event_openssl.c — How SSL is implemented by swapping c->recv/send function pointers
HTTP/2: src/http/v2/ — HTTP/2 frame parsing and multiplexing
QUIC/HTTP/3: src/event/quic/ + src/http/v3/ — QUIC transport layer and HTTP/3 implementation

3. Design Patterns and Mindset Throughout

3.1 Intrusive Data Structures

nginx does not separately allocate list nodes or tree nodes. Instead, ngx_queue_t and ngx_rbtree_node_t are directly embedded in the structs that use them. Zero extra allocation, extreme efficiency.

// Not: list<Item*> items (malloc a node for every insertion)
// Instead: Item contains ngx_queue_t queue, linked in directly

3.2 Pre-allocation + Reuse

Connections, events, memory pools — all pre-allocated at startup, no malloc at runtime. nginx’s philosophy: “Whatever maximum resources I can calculate at startup, I pre-allocate.”

3.3 I/O Function Pointer Polymorphism

c->recv = ngx_ssl_recv;   // SSL module silently swaps these
c->send = ngx_ssl_send;

Higher-level code (the HTTP framework) is completely unaware whether the underlying transport is TCP, SSL, or QUIC. This is nginx’s key technique for protocol upgrades and SSL transparency.

3.4 Return-Value-Driven Control Flow

nginx does not use exceptions or goto. Instead, control intent is expressed through return values:

Return Value	Semantics
`NGX_OK`	Done, caller continues
`NGX_ERROR`	Error, abort
`NGX_AGAIN`	Insufficient resources (buffer full, data not arrived yet), pause and wait for the next event trigger
`NGX_DECLINED`	I won’t handle this, try the next one (core of handler singly-linked list traversal)
`NGX_DONE`	Handled, but the request is not finished (async operation pending)
`NGX_BUSY`	Busy, retry later

Understanding the difference between NGX_AGAIN and NGX_DECLINED is particularly important — the former means “wait a bit and I’ll retry”, the latter means “move on to the next one.”

3.5 Graceful Zero-Downtime

The core logic of configuration reload (nginx -s reload):

Master receives SIGHUP → creates a new ngx_cycle_t, forks new workers
Old workers receive SIGQUIT → graceful shutdown (finish existing connections before exiting)
Old and new workers briefly coexist; once old workers exit, the new cycle takes over

This relies on the cycle->old_cycle design: the new cycle holds a reference to the old cycle, releasing it after old workers exit.

4. Debugging Tips

4.1 Debug Logging

Build with --with-debug, then set in the configuration:

error_log /var/log/nginx/debug.log debug;

4.2 Common GDB Breakpoints

# Event loop entry
b ngx_process_events_and_timers

# Request processing entry
b ngx_http_process_request

# Phase engine
b ngx_http_core_run_phases

# Connection allocation
b ngx_get_connection

# Upstream connection
b ngx_http_upstream_connect

# All recv/send calls on a connection
b ngx_unix_recv
b ngx_unix_send

4.3 Printing ngx_str_t

# ngx_str_t is not a C string — needs custom printing in GDB
define print_ngx_str
  set $s = (ngx_str_t*)$arg0
  printf "%.*s\n", $s->len, $s->data
end

4.4 Tracing Memory Allocation

Set breakpoints at key functions in src/core/ngx_palloc.c:

ngx_create_pool — Pool creation
ngx_palloc — Small block allocation
ngx_palloc_block — Allocate new pool block
ngx_pfree — Large block free
ngx_destroy_pool — Pool destruction

5. Recommended Reading Practices

Don’t try to read sequentially by file number. nginx has many static functions and global variables. Read by header file dependency relationships.
Trace one functional path at a time. For example, “the complete path of an HTTP GET request from reception to response” — only focus on functions on this path, ignore side branches.
Draw diagrams. Struct nesting in nginx source code is very deep. Hand-drawing the following relationship diagrams will be very helpful:
- ngx_cycle_t → conf_ctx → indexing relationships of each module’s configuration
- ngx_connection_t → read / write → ngx_event_t → handler call chain
- The checker → handler → next jump relationships in the HTTP phase engine
- The ngx_http_top_header_filter → next → … order in the filter chain
Start from simple third-party modules. Read simple modules at the level of src/http/modules/ngx_http_echo_module.c to understand how handlers and filters are written.
Comparative reading. Find two modules with similar functionality under src/http/modules/ (e.g., proxy vs fastcgi) and understand where they differ.
Re-read core functions. ngx_process_events_and_timers(), ngx_http_core_run_phases(), ngx_conf_parse(), ngx_http_upstream_connect() — these functions are worth reading repeatedly; you’ll discover new details each time.

6. Core File Index

File	Priority	Core Content
`src/core/nginx.c`	★★★	`main()` entry point
`src/core/ngx_cycle.c`	★★★	`ngx_init_cycle()` cycle initialization
`src/core/ngx_palloc.c`	★★★	Memory pool implementation
`src/core/ngx_buf.c`	★★★	Buffer and chain operations
`src/core/ngx_connection.c`	★★★	Connection pre-allocation and management
`src/core/ngx_conf_file.c`	★★★	Configuration parser
`src/core/ngx_module.c`	★★★	Module loading and initialization
`src/core/ngx_string.c`	★★☆	String utility function collection
`src/core/ngx_array.h`	★★★	Dynamic array
`src/core/ngx_list.h`	★★★	Linked list + array hybrid
`src/core/ngx_queue.h`	★★★	Intrusive doubly-linked list
`src/core/ngx_rbtree.c`	★★☆	Red-black tree
`src/core/ngx_hash.c`	★★☆	Static hash table
`src/core/ngx_log.c`	★★☆	Logging system
`src/os/unix/ngx_process_cycle.c`	★★★	Master/worker process management
`src/event/ngx_event.c`	★★★	Event loop core
`src/event/ngx_event_accept.c`	★★☆	Accept and thundering herd handling
`src/event/ngx_event_timer.h`	★★☆	Timer management
`src/event/modules/ngx_epoll_module.c`	★★☆	epoll event module
`src/http/ngx_http.c`	★★★	HTTP framework initialization
`src/http/ngx_http_request.c`	★★★	Request lifecycle
`src/http/ngx_http_core_module.c`	★★★	Core directives, phase checkers
`src/http/ngx_http_upstream.c`	★★★	Upstream proxy mechanism
`src/http/ngx_http_variables.c`	★★☆	Variable system
`src/http/ngx_http_header_filter.c`	★★☆	Response header serialization
`src/http/ngx_http_write_filter.c`	★★☆	Final send to socket
`src/http/modules/ngx_http_proxy_module.c`	★★☆	Typical HTTP proxy module
`src/http/modules/ngx_http_static_module.c`	★☆☆	Simplest content handler

Final advice: Reading the nginx source code is a marathon, not a sprint. The core code is about 100K lines, but the design is highly consistent. Once you master the patterns in the first 30%, the remaining 70% will go much faster. Happy reading!

Problem 177: 第N高的薪水

2021-02-23T08:05:02+08:00

177. 第N高的薪水

编写一个 SQL 查询，获取 Employee 表中第 n 高的薪水（Salary）。

Id	Salary
1	100
2	200
3	300

例如上述 Employee 表，n = 2 时，应返回第二高的薪水 200。如果不存在第 n 高的薪水，那么查询应返回 null。

getNthHighestSalary(2)
200

sql脚本：

Create table If Not Exists Employee (Id int, Salary int);
Truncate table Employee;
insert into Employee (Id, Salary) values (1, 100);
insert into Employee (Id, Salary) values (2, 200);
insert into Employee (Id, Salary) values (3, 300);

解答

解法一：

CREATE FUNCTION getNthHighestSalary(N INT) RETURNS INT
BEGIN
		SET N := N - 1;
  RETURN (
      # Write your MySQL query statement below.
      SELECT (SELECT DISTINCT Salary FROM Employee ORDER BY Salary DESC LIMIT N, 1)
  );
END

MySQL直接执行会遇到报错信息，解决方案请参考：DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled

Problem 177: Nth Highest Salary

2021-02-23T08:05:02+08:00

177. Nth Highest Salary

Write a SQL query to get the nth highest salary from the Employee table.

Id	Salary
1	100
2	200
3	300

For example, given the above Employee table, the nth highest salary where n = 2 is 200. If there is no nth highest salary, the query should return null.

getNthHighestSalary(2)
200

SQL script:

Create table If Not Exists Employee (Id int, Salary int);
Truncate table Employee;
insert into Employee (Id, Salary) values (1, 100);
insert into Employee (Id, Salary) values (2, 200);
insert into Employee (Id, Salary) values (3, 300);

Solution

Solution 1:

CREATE FUNCTION getNthHighestSalary(N INT) RETURNS INT
BEGIN
    SET N := N - 1;
  RETURN (
      # Write your MySQL query statement below.
      SELECT (SELECT DISTINCT Salary FROM Employee ORDER BY Salary DESC LIMIT N, 1)
  );
END

If you encounter errors running this directly in MySQL, refer to: DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled

Git简易教程

2021-02-21T21:51:18+08:00

将暂存区中文件恢复为和HEAD一样

git reset HEAD 将暂存区中所有文件恢复为和HEAD一样

git reset HEAD -- [filename] 将暂存区中名字为filename的文件恢复为和HEAD一样

比较暂存区和HEAD所含文件差异

git diff --cached

比较工作区和暂存区所含文件差异

git diff 默认比较暂存区和工作区的文件的区别

git diff -- [filename] 比较工作区和暂存区中名字为filename的文件的内容的区别

将工作区中文件内容恢复为和暂存区中一样

git checkout -- [filename] 将工作区中的名字为filename的文件恢复为和暂存区中一样

将暂存区和工作区的内容恢复至某次commit

git reset --hard [commit code] 将工作区和暂存区中的内容恢复至与某次commit一样【慎用】

查看不同commit的指定文件的差异

git diff [commit code 1] [commit code 2] -- [filename]

删除暂存区和工作区指定文件

git rm [filename]

将变更进行存入临时栈空间

git stash 将变更存入栈空间

git stash apply 栈空间中的内容仍存在

git stash pop 栈空间中的内容被移除

git仓库备份

git clone --bare [remote git repository] [local git repository] 哑协议方式

git clone --bare [file:///<remote git repository>] [local git repository] 智能协议方式

git remote add [remote repository name] [file:///<remote git repository>]

git push --set-upstream [remote repository name] [branch name] 将本地分支推送至远程仓库

git push [remote repository name] [branch name] 将本地分支推送至远程仓库

Git Tutorial

2021-02-21T21:51:18+08:00

Restore files in staging area to match HEAD

git reset HEAD restores all files in staging area to match HEAD

git reset HEAD -- [filename] restores the specified file in staging area to match HEAD

Compare differences between staging area and HEAD

git diff --cached

Compare differences between working directory and staging area

git diff compares differences between staging area and working directory

git diff -- [filename] compares differences for the specified file

Restore working directory files to match staging area

git checkout -- [filename] restores the specified file in working directory to match staging area

Restore both staging area and working directory to a specific commit

git reset --hard [commit code] restores both staging area and working directory to match a specific commit [use with caution]

Compare differences for a specified file between different commits

git diff [commit code 1] [commit code 2] -- [filename]

Remove a file from both staging area and working directory

git rm [filename]

Stash changes to a temporary stack

git stash saves changes to the stack

git stash apply applies changes while keeping them in the stack

git stash pop applies changes and removes them from the stack

Git repository backup

git clone --bare [remote git repository] [local git repository] using dumb protocol

git clone --bare [file:///<remote git repository>] [local git repository] using smart protocol

git remote add [remote repository name] [file:///<remote git repository>]

git push --set-upstream [remote repository name] [branch name] push local branch to remote repository

git push [remote repository name] [branch name] push local branch to remote repository

Problem 175: 组合两个表

2021-02-17T22:02:22+08:00

175. 组合两个表

表1: Person

列名	类型
PersonId	int
FirstName	varchar
LastName	varchar

PersonId 是上表主键

表2: Address

列名	类型
AddressId	int
PersonId	int
City	varchar
State	varchar

AddressId 是上表主键

编写一个 SQL 查询，满足条件：无论 person 是否有地址信息，都需要基于上述两表提供 person 的以下信息：

FirstName, LastName, City, State

sql脚本：

Create table Person (PersonId int, FirstName varchar(255), LastName varchar(255));
Create table Address (AddressId int, PersonId int, City varchar(255), State varchar(255));
Truncate table Person;
insert into Person (PersonId, LastName, FirstName) values ('1', 'Wang', 'Allen');
Truncate table Address;
insert into Address (AddressId, PersonId, City, State) values ('1', '2', 'New York City', 'New York');

解答

解法一：左联结（LEFT JOIN）

SELECT
	FirstName,
	LastName,
	City,
	State
FROM
	Person
	LEFT JOIN
	Address ON (Person.PersonId = Address.PersonId);

Problem 175: Combine Two Tables

2021-02-17T22:02:22+08:00

175. Combine Two Tables

Table 1: Person

Column Name	Type
PersonId	int
FirstName	varchar
LastName	varchar

PersonId is the primary key for this table.

Table 2: Address

Column Name	Type
AddressId	int
PersonId	int
City	varchar
State	varchar

AddressId is the primary key for this table.

Write a SQL query that provides the following information for each person in the Person table, regardless of whether there is an address entry for that person:

FirstName, LastName, City, State

SQL script:

Create table Person (PersonId int, FirstName varchar(255), LastName varchar(255));
Create table Address (AddressId int, PersonId int, City varchar(255), State varchar(255));
Truncate table Person;
insert into Person (PersonId, LastName, FirstName) values ('1', 'Wang', 'Allen');
Truncate table Address;
insert into Address (AddressId, PersonId, City, State) values ('1', '2', 'New York City', 'New York');

Solution

Solution 1: LEFT JOIN

SELECT
    FirstName,
    LastName,
    City,
    State
FROM
    Person
    LEFT JOIN
    Address ON (Person.PersonId = Address.PersonId);