数据库

Python 的 ORM 生态比较分散，没有像 Rails ActiveRecord 那样一统天下的选择。这篇文章对比一下我用过的几个。 SQLAlchemy：工业级首选 SQLAlchemy 是 Python 生态里最成熟、功能最强的 ORM，分两层： Core：SQL 表达式语言，接近裸 SQL ORM：高级对象映射层 from sqlalchemy import create_engine, Column, Integer, String, ForeignKey from sqlalchemy.orm import DeclarativeBase, relationship, Session engine = create_engine("mysql+pymysql://user:pass@localhost/mydb") class Base(DeclarativeBase): pass class User(Base): __tablename__ = "users" id = Column(Integer, primary_key=True) name = Column(String(50), nullable=False) email = Column(String(100), unique=True) orders = relationship("Order", back_populates="user") class Order(Base): __tablename__ = "orders" id = Column(Integer, primary_key=True) user_id = Column(Integer, ForeignKey("users.id")) total = Column(Integer) user = relationship("User", back_populates="orders") # 查询 with Session(engine) as session: users = session.query(User).filter(User.name.like("K%")).all() # 预加载关联数据（避免 N+1 问题） from sqlalchemy.orm import selectinload users = session.query(User).options(selectinload(User.orders)).all() SQLAlchemy 2.0 新语法（推荐）： from sqlalchemy import select with Session(engine) as session: stmt = select(User).where(User.name.like("K%")) users = session.execute(stmt).scalars().all() 优点：功能极强，支持复杂查询，文档完善，生态成熟。 缺点：学习曲线陡，概念多（Session、Unit of Work、lazy loading……）。 Tortoise-ORM：异步场景的选择 专为 asyncio 设计，和 FastAPI 配合很顺手： ...

线上接口突然变慢，大概率是数据库查询出了问题。这篇文章梳理一下排查慢查询的完整流程。 开启慢查询日志 -- 查看当前配置 SHOW VARIABLES LIKE 'slow_query%'; SHOW VARIABLES LIKE 'long_query_time'; -- 临时开启（重启失效） SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; -- 超过 1 秒的查询记录 SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log'; -- 永久配置（写入 my.cnf） [mysqld] slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = 1 # 记录未使用索引的查询 用 pt-query-digest 分析 手动看慢查询日志很费时，pt-query-digest（Percona Toolkit）可以聚合分析： pt-query-digest /var/log/mysql/slow.log | head -100 输出会按响应时间降序列出各类查询，告诉你哪些查询最值得优化： # Query 1: 0.50 QPS, 2.50x concurrency, ID 0xABC123 # This item is included in the report because it matches --limit. # pct total min max avg 95% stddev median # Count 15 1000 # Exec time 80% 200s 0.1s 5s 0.2s 0.5s 0.3s 0.15s # Rows sent 5% 500 0 10 0 1 1 0 # Rows examine 90% 900k 100 5000 900 2000 800 600 重点关注 Rows examine（扫描行数）和 Exec time（执行时间）。 ...

事务和锁是 MySQL 里最复杂也最容易出问题的部分。这篇文章从实际问题出发，梳理核心概念和排查思路。 事务隔离级别 MySQL 有四种隔离级别，对应不同的并发问题： 隔离级别 脏读 不可重复读 幻读 READ UNCOMMITTED ✓ 可能 ✓ 可能 ✓ 可能 READ COMMITTED ✗ 不会 ✓ 可能 ✓ 可能 REPEATABLE READ（默认） ✗ 不会 ✗ 不会 部分解决 SERIALIZABLE ✗ 不会 ✗ 不会 ✗ 不会 InnoDB 默认是 REPEATABLE READ，并且通过 MVCC + Gap Lock 解决了大部分幻读问题。 InnoDB 的锁类型 行锁（最常用）： 共享锁（S 锁）：SELECT ... LOCK IN SHARE MODE，允许多个事务同时读 排他锁（X 锁）：SELECT ... FOR UPDATE 或增删改，同一时间只有一个事务能持有 意向锁：表级别的锁，表示"我将要对某些行加行锁"，用于快速判断表级操作是否冲突。 Gap Lock（间隙锁）：锁定索引记录之间的间隙，防止插入新记录，解决幻读。 Next-Key Lock：行锁 + Gap Lock 的组合，InnoDB 在 REPEATABLE READ 下默认使用。 ...

面试必考，工作必用。索引这个话题说简单也简单，说复杂也复杂。这篇文章尝试把最实用的部分说清楚。 B+ 树索引的工作原理 MySQL InnoDB 的索引底层是 B+ 树。B+ 树的特点： 所有数据存在叶子节点 叶子节点之间用链表相连（支持范围查询） 非叶子节点只存键值，不存数据（让每层能存更多节点） 这意味着一次查询最多只需要走 树高 次 IO。对于千万级的表，B+ 树高度通常只有 3-4 层，也就是 3-4 次 IO 就能找到数据。 聚簇索引 vs 二级索引 聚簇索引（主键索引）：叶子节点直接存行数据。 二级索引（普通索引）：叶子节点存的是主键值，查到后还需要回表（再走一次聚簇索引）。 -- 走二级索引，需要回表 SELECT * FROM users WHERE name = 'Kada'; -- 覆盖索引，不需要回表（索引包含了所有需要的字段） SELECT id, name FROM users WHERE name = 'Kada'; 覆盖索引是避免回表的常用技巧，查询的字段都在索引里，就不用回表了。 联合索引的最左前缀原则 -- 建了联合索引 (a, b, c) CREATE INDEX idx_abc ON t (a, b, c); -- 能用到索引 WHERE a = 1 WHERE a = 1 AND b = 2 WHERE a = 1 AND b = 2 AND c = 3 -- 不能用到索引（跳过了 a） WHERE b = 2 WHERE c = 3 WHERE b = 2 AND c = 3 联合索引按最左前缀匹配，中间不能断。 ...