跳至主要内容

博文

SQL 等价改写优化案例集

范围说明:本文档只收录 不新增索引、不改表结构、仅靠改写SQL本身 就能拿到显著性能收益的案例。每个案例包含:问题场景、根因分析、改写方案、生效的前提条件、以及如何用 EXPLAIN 验证效果。默认以 MySQL 8.0 / InnoDB 为背景,个别案例会注明与 PostgreSQL 的差异。 案例一:深分页 —— 延迟关联(Deferred Join) 场景 订单表按状态筛选后翻到很靠后的页码,是后台管理系统里最常见的慢查询之一。 CREATE TABLE orders ( id BIGINT PRIMARY KEY , customer_id BIGINT NOT NULL , status VARCHAR ( 20 ) NOT NULL , create_time DATETIME NOT NULL , buyer_name VARCHAR ( 50 ), address VARCHAR ( 200 ), remark VARCHAR ( 500 ) -- 其余字段省略,实际共30+列 ); CREATE INDEX idx_status_time ON orders( status , create_time); SELECT * FROM orders WHERE status = 'shipped' ORDER BY create_time LIMIT 1000000 , 20 ; 根因 idx_status_time 是二级索引,叶子节点只存 (status, create_time, id) ,不含其余字段。执行过程是: 1. 在二级索引上定位 status='shipped' 的记录,按 create_time 排序; 2. 每扫到一行,都要拿 id 回聚簇索引取完整行(回表); 3. 前 1,000,000 行取出来后 直接丢弃 ,只保留最后 20 行。 问题的本质不是"排序慢",而是 做了 1,000,020 次没必要的回表 I/O 。 改写 SELECT o.* FROM ...
阅读全文
最新博文

ClickHouse与MySQL的区别对比指南

ClickHouse 与 MySQL 对比指南 —— 写给有 MySQL 经验的用户 一、先说结论：两者根本不是同一类数据库 理解 ClickHouse 最容易踩的坑，就是把它当成"性能更强的 MySQL"。实际上两者的设计目标完全不同： 维度 MySQL ClickHouse 定位 OLTP（联机事务处理） OLAP（联机分析处理） 典型场景 下单、支付、用户信息增删改查 日志分析、报表、BI、时序数据、用户行为分析 存储方式 行式存储（row-based） 列式存储（column-based） 单次查询数据量 少量行，高频次 大量行，低频次但计算量大 事务 完整 ACID 事务 不支持传统事务，写入近似"追加" 单条数据修改 高效（UPDATE/DELETE 直接改） 低效，官方不推荐频繁做 一句话理解： MySQL 擅长"找到某一行/几行数据并精确修改"，ClickHouse 擅长"扫描亿万行数据做聚合计算"。 二、使用方式与功能对比 2.1 建表语法差异 MySQL： CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY , user_id BIGINT , amount DECIMAL ( 10 , 2 ), created_at DATETIME ) ENGINE = InnoDB ; ClickHouse： CREATE TABLE orders ( id UInt64, user_id UInt64, amount Decimal ( 10 , 2 ), created_at DateTime ) ENGINE = MergeTree() ORDER BY (user_id, created_at) PARTITION BY toYYYYMM(created_at); 几个关键差异点： 没有 AUTO_INCREMENT ：ClickHouse 没有自增主键的概念，通常用雪花算法、UUID 或业务自带的唯一键。 ...
阅读全文

PostgreSQL与MySQL的主要区别和架构介绍

PostgreSQL 入门指南：写给熟悉 MySQL 的开发者 本文面向已经掌握 MySQL 的读者，目的是快速建立 PostgreSQL 的知识框架，内容分四部分：基础用法差异、内部架构对比、索引机制对比、数据存储与流动过程。 一、基础用法差异 1.1 连接与客户端 MySQL PostgreSQL 命令行客户端 mysql -u root -p psql -U postgres -d mydb 默认端口 3306 5432 认证配置 mysql.user 表 pg_hba.conf ，与角色系统分离 1.2 数据类型差异 用途 MySQL PostgreSQL 自增主键 AUTO_INCREMENT GENERATED ALWAYS AS IDENTITY （新写法）或 SERIAL （旧写法，底层是 SEQUENCE） 布尔值 常用 TINYINT(1) 模拟 原生 BOOLEAN JSON JSON JSON 和 JSONB （二进制存储、可建索引，通常首选） 数组 不支持，需用逗号拼接字符串或 JSON 原生 ARRAY 类型，如 INT[] 枚举 ENUM('a','b') 需 CREATE TYPE ... AS ENUM ，或改用 CHECK 约束 UUID CHAR(36) 或 BINARY(16) 原生 UUID 类型 1.3 标识符大小写规则（重要易错点） MySQL：表名大小写敏感性取决于操作系统（Linux 敏感、Windows 不敏感），列名一般不敏感。 PostgreSQL： 所有未加双引号的标识符都会被自动转成小写 。 SELECT * FROM MyTable 等价于 select * from mytable 。如果建表时用双引号保留了大小写（如 "MyTable" ），之后每次引用都必须加双引号，否则会报"关系不存在"的错误。 字符串必须用单引号；双引号在 PostgreSQL 中专门用于标识符，不能像 MySQL 那样偶尔"双引号当字符串用"。 1.4 自增主键写法对...
阅读全文

Elasticsearch从入门到精通指南

Elasticsearch 从入门到精通 面向有编程基础的读者。全文以「概念 → 用法 → 原理 → 进阶」的顺序展开，代码示例均为 Elasticsearch 9.x（截至 2026 年中的稳定版本，特性以 Retriever API / ES|QL 为主）。 目录 Elasticsearch 是什么 核心概念 快速上手：REST API 基础操作 Mapping 与字段类型 查询 DSL 基础 聚合（Aggregations） 集群架构深入 底层数据结构 相关性打分与 Rank 排序 向量搜索（Vector Search） 混合搜索与 Retriever 框架 生产实践与性能调优 学习路径建议 1. Elasticsearch 是什么 Elasticsearch（简称 ES）是一个基于 Apache Lucene 构建的分布式搜索与分析引擎。理解它，最好从三个关键词入手： 搜索引擎 ：底层是倒排索引，擅长全文检索、相关性排序。 分布式系统 ：数据自动分片（shard）并可跨节点复制，具备水平扩展和高可用能力。 近实时（Near Real-Time）分析引擎 ：不仅能搜索，还能做聚合统计，因此常被用作日志分析（ELK/Elastic Stack）、可观测性、向量检索/RAG 的后端。 一句话总结： ES = 分布式的 Lucene + REST API + 集群管理能力 。Lucene 负责单机上的索引与检索算法，ES 负责把多台机器上的多个 Lucene 实例组织成一个逻辑整体，并提供 JSON/REST 的开发者友好接口。 2. 核心概念 概念 类比（关系型数据库） 说明 Index（索引） Database / Table 具有相同 mapping 的文档集合 Document（文档） Row 一条 JSON 数据，是 ES 中最小的可搜索单元 Field（字段） Column 文档中的一个键值对 Mapping Schema 定义字段类型、分词方式等 Shard（分片） 分区（Partition） 索引被水平切分成的 Lucene 实例，是并行与扩展的基本单位 Replica（副本） 冗余备份 分片的复制，用于容灾和读...
阅读全文