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

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

MySQL 和 Elasticsearch 的定位差异

在分布式高并发的后端架构中，数据库死锁（Deadlock）就像一个幽灵。尽管 InnoDB 引擎具备全自动的自救回滚机制，但频繁出现的死锁报错（错误码 1213）不仅会吞噬系统吞吐量，更是代码健壮性不足的显性信号。本文去掉生活化的类比，直接从资源竞争的结构本质出发，层层递进地拆解 MySQL 死锁的底层逻辑。

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

2. MySQL死锁问题分析

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

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

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

MySQL 中 NULL 的处理与普通值不同，需要特别注意。

给字符串类型的字段建立索引效率不高，但如果需要经常查询这个字段，可以通过 CRC32 转换来提高查询效率。

假设有一个字符串字段 sys_trans_id，需要频繁查询。可以新增一个整型字段 sys_trans_id_crc32 来存储 CRC32 的值，并在这个字段上建立索引。