MySQL 的锁是很多线上事故的“隐形主角”——超卖、死锁、慢查询拖垮整个库，往往都能追到锁上。本文从并发下为什么需要锁讲起，把 InnoDB 的全局锁、表锁、MDL、行锁、间隙锁、Next-Key Lock 一层层拆开，再用 Metrics-Driven Development 的方式定义业务、应用和数据库指标，演示如何发现、定位、改进和验证锁问题，最后讨论 MySQL、Redis、ZooKeeper/etcd 分布式锁的边界。

一份 MySQL 数据库设计评审清单，我把它拆成"建表""查询""特殊约束"三块，并逐条讲清楚背后的原因——为什么禁自增主键、为什么禁外键、为什么用 DATETIME 不用 TIMESTAMP、为什么少碰 JSON 和大字段。规则好背，难的是知道每条规则在防哪个坑。文末附一份可直接抄的自查清单。

用 secrets_action_history 记录 secrets 表的新增、修改和删除，看起来像一个小需求，其实踩中了变更索引、审计、备份、review、性能、数据生命周期和 MySQL 分区限制这几块地雷。本文讨论这个方案是否靠谱，并给出按时间窗口拉取变更、定时清理、分区维护和巡检的落地方案。

数据库挂了，整个系统就瘫了——MySQL 高可用不是"锦上添花"，而是"保命底线"。本文梳理 MySQL 高可用的主流方案(主从复制、半同步、MHA、InnoDB Cluster、Galera)，对比它们的适用场景和踩坑经验，附带常见错误排查清单。