InnoDB

«结论先行：在 InnoDB 里，往带唯一索引的表并发 INSERT，最常见的死锁根因不是「写写竞争」，而是 Duplicate Key 检查触发的 S 锁 + 间隙锁，叠加自增主键的插入顺序不一致，形成 AB-BA 环路。这个坑我踩了两次

一、现象：一个"数数"接口把从库拖到 9 秒 先说结论：在 InnoDB 里，"SELECT COUNT(*) FROM t" 不是"数个数"，而是全表扫描——它要顺着聚簇索引把整张表的行一条条走一遍才能得出一个数。 我们内部有个"资产总览

【背景】 我们是一套 MySQL 8.0.32 / InnoDB 的订单查询服务，核心表 t_order 约 5200 万行、单表 9.8GB（含二级索引）。高频查询按 (merchant_id, status, create_time)

背景：MySQL 8.0.36，InnoDB，一张约 5000 万行的日志表 access_log，主键 id，二级索引 idx_path (path)，idx_path_status (path, status)，idx_time (cr

背景：MySQL 8.0.36，主从架构（单主 + 1 从，半同步），主库一台 16C/64G/ESSD，从库同规格。业务在每天 02:00–03:30 跑一次订单归档批处理：把 orders 表里 create_time 早于 90 天的

背景：MySQL 8.0.36，InnoDB，一张约 1200 万行的订单表 orders，现有复合索引 idx_a_b_c (a, b, c)，a 是租户 id（bigint，等值），b 是订单时间（datetime，范围），c 是状态（

背景：MySQL 8.0.36，InnoDB 单表（约 8000 万行），主键为自增 id。业务方反馈：连续 2 天内 id 出现约 3 万次的跳号，期间没有观察到批量插入，也没有触发器或 AFTER INSERT 钩子。 现象： 1) S