做业务开发的同学，大概都有过被 MySQL 慢查询折磨的经历——明明索引建了、数据量也不大，接口却总是超时。常规的加索引、加缓存套路固然有效，但有时候换个思路反而能四两拨千斤。本文整理了项目中几个真实慢查询案例的优化思路，部分方案稍显「偏门」，但亲测有效。

一条看似简单的 SELECT * FROM user WHERE id = 1;，在 MySQL 5.7 内部其实穿越了多层组件、多个内存数据结构、多种日志，才最终把结果返回给你。本文以 MySQL 5.7 为基线（其核心机制在 5.7 / 8.0 之间高度一致，差异点会单独标注），从一名数据库内核工程师的视角，把这条链路完整拆开。

在做系统设计时，数据库选型是一个关键决策。MySQL 和 Elasticsearch 是两种不同定位的存储方案，今天结合实际项目经验，系统性地对比一下它们的适用场景。

MySQL 和 Elasticsearch 的定位差异

1. MySQL商品库存扣减问题总结

2. MySQL死锁问题分析

3. Go: 理解 Sync.Pool 的设计

4. epoll 或者 kqueue 的原理是什么？

5. 深入理解 MySQL ―― 锁、事务与并发控制