ORDER BY 是日常开发中最常用的 SQL 子句之一，但在遇到 NULL 空值、需要将特定行置顶或置底时，不同数据库的默认行为差异常常让人踩坑。
本文系统梳理 MySQL、Oracle、SQL Server、PostgreSQL 四种主流数据库在 ORDER BY 场景下的处理方式与最佳实践，助你写出可移植、可维护的排序 SQL。

一、为什么 ORDER BY 的"边角料"值得重视

在业务系统中，以下场景你一定不陌生：

1. 列表页按创建时间倒序，但还没填写创建时间的记录（NULL）要么全部堆在最前面、要么全部沉到底部，产品经理说"应该放到最后"。
2. 下拉选项中，"全部""其他""请选择"这类占位项需要置顶，其他选项按字母或编码排序。
3. 报表数据中，"合计行"这一条必须放在表格最底部，而不是被排序规则打乱。
4. 审批流列表中，"草稿"状态的单据要置顶显示，"已归档"的要沉底，中间是正常流程。

EXPLAIN 是 MySQL 查询优化的"X 光机"。一条 SQL 跑得慢，不猜、不试，先 EXPLAIN 一把，执行计划一目了然。本文从 12 个字段逐个拆解，配合真实案例与原理图解，带你从"看懂"到"能优化"。

一、EXPLAIN 是什么

当你对一条 SELECT 语句加上 EXPLAIN 前缀时，MySQL 不会真正执行这条 SQL，而是返回一个"执行计划"——它告诉你 MySQL 打算怎么走索引、扫描多少行、是否用到临时表等。

当单表数据突破千万级，单库扛不住读写并发，分库分表就成了必选项。但分完之后，跨库 JOIN 怎么办？分布式事务怎么搞？选哪个中间件？本文从架构原理、分片策略、跨库查询、分布式事务到迁移方案，全面对比三大主流中间件。

一、为什么需要分库分表

1.1 单库瓶颈

┌────────────────────────────────────────────────┐
│              单库 MySQL 性能瓶颈                 │
├────────────────────────────────────────────────┤
│                                                │
│  数据量维度：                                    │
│  ┌──────────┬──────────────────────────────┐  │
│  │ < 500万  │ 性能良好，正常索引即可        │  │
│  │ 500-1000万│ 需要优化索引，查询变慢        │  │
│  │ 1000-5000万│ 必须深度优化，分表考虑       │  │
│  │ > 5000万 │ 强烈建议分库分表              │  │
│  └──────────┴──────────────────────────────┘  │
│                                                │
│  并发维度：                                      │
│  ┌──────────┬──────────────────────────────┐  │
│  │ QPS < 1000│ 单机可承载                   │  │
│  │ QPS 1000-5000│ 读写分离 + 缓存            │  │
│  │ QPS > 5000│ 需要分库分散压力             │  │
│  └──────────┴──────────────────────────────┘  │
│                                                │
│  瓶颈点：                                       │
│  1. 磁盘 I/O — 数据量大时随机读写变慢           │
│  2. 内存 — buffer pool 命中率下降              │
│  3. 锁竞争 — 大表 DDL 耗时极长                 │
│  4. 复制延迟 — binlog 太大，从库追不上          │
│  5. 备份恢复 — 单库备份耗时长                  │
│                                                │
└────────────────────────────────────────────────┘

线上 MySQL 突然变慢？慢查询日志堆了几十个 G？怎么定位、怎么分析、怎么治理？pt-query-digest 怎么用？加索引会不会锁表？一篇讲透慢查询全流程治理。

一、慢查询日志

1.1 开启与配置

-- 查看慢查询配置
SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';

-- 开启慢查询日志
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;           -- 超过 1s 的查询记录
SET GLOBAL log_queries_not_using_indexes = ON;  -- 记录未用索引的查询
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL min_examined_row_limit = 100;  -- 扫描行数 < 100 不记录

-- 持久化配置（my.cnf）
[mysqld]
slow_query_log = ON
long_query_time = 1
log_queries_not_using_indexes = ON
slow_query_log_file = /var/log/mysql/slow.log
min_examined_row_limit = 100
log_slow_admin_statements = ON   -- 记录慢 DDL
log_slow_slave_statements = ON   -- 记录从库慢查询

-- 慢查询日志格式
-- Time: 2024-06-01T10:23:45.123456Z
-- User@Host: app[app] @ [10.0.0.1]  Id: 12345
-- Query_time: 2.345678  Lock_time: 0.000123  Rows_sent: 10  Rows_examined: 1000000
-- SET timestamp=1717235025;
-- SELECT * FROM orders WHERE user_id = 12345 ORDER BY create_time DESC;

数据库高可用是后端架构的生命线。主库挂了怎么办？数据会不会丢？切换要多久？本文对比四种主流 MySQL 高可用方案，从架构原理到生产实践，帮你做出正确选型。

一、为什么需要高可用

高可用核心指标：

上午 10 点，618 大促正在如火如荼进行，你收到钉钉告警：订单库慢查询数从每分钟 5 条飙升到 2000 条，数据库 CPU 从 30% 跳到 90%，接口 P99 从 50ms 涨到 3000ms。用户开始在 App 上看到加载转圈。这是 DBA 和开发面临的最紧张场景之一——慢查询突增。

一、慢查询突增的常见触发因素

慢查询突增往往不是"突然出现了慢 SQL"，而是"原来快的 SQL 突然变慢了"。理解触发因素是快速定位的前提。

1.1 触发因素全景图

分库分表实战：ShardingSphere 使用指南是系统设计的核心，它决定了数据的存储方式和访问效率。
本文介绍了分库分表实战：ShardingSphere 使用指南的原理和最佳实践，帮助你构建高效的数据存储方案。

MySQL 单库单表会遇到以下瓶颈：

事务是数据库的基石。面试被问"MVCC 怎么实现的"答不上来？线上遇到"快照读和当前读结果不一致"排查不了？从 ACID 到底层实现，一篇讲透。

一、ACID 四大特性

A（Atomicity）原子性：事务要么全部成功，要么全部回滚
  → 实现：undo log（回滚日志）

C（Consistency）一致性：事务前后数据保持一致
  → 实现：A + I + D 共同保证

I（Isolation）隔离性：并发事务互不干扰
  → 实现：MVCC + 锁

D（Durability）持久性：事务提交后永久保存
  → 实现：redo log（重做日志）

线上接口突然变慢？慢查询日志暴涨？CPU 飙升？90% 的数据库性能问题都是索引问题。从 B+ 树底层原理到生产实战，一篇讲透 MySQL 索引优化。

一、B+ 树索引原理

1.1 为什么是 B+ 树

B 树（B-Tree）：
  每个节点存数据 → 一个节点能存的 key 少 → 树更高 → 磁盘 IO 更多

B+ 树（B+ Tree）：
  非叶子节点只存 key → 一个节点能存更多 key → 树更矮 → IO 更少
  数据只存叶子节点 → 叶子节点用双向链表连接 → 范围查询极快

MySQL InnoDB 选择 B+ 树的原因：
  1. 磁盘 IO 少（树矮，通常 3-4 层即可存千万级数据）
  2. 范围查询快（叶子节点链表，一次定位后顺序扫描）
  3. 查询稳定（每次都查到叶子节点，时间复杂度稳定 O(logN)）

MySQL是世界上最流行的开源关系型数据库，它为Web应用提供了稳定可靠的数据存储方案。
本文系统梳理了MySQL的核心概念和最佳实践，是后端开发者的必备知识。

没有索引时，MySQL 查找一条记录需要全表扫描（从头到尾扫一遍）。对于 1000 万行的表，这意味着扫描 1000 万行数据。

有索引时，MySQL 通过 B+ 树查找，只需要 3-4 次磁盘 I/O 就能找到目标数据。

类比： 索引就像字典的目录。没有目录，找一个字得翻完整本字典；有目录，先查目录定位到页码，直接翻到那一页。