标签频道
InnoDB
该标签下的文章、提问与讨论帖。
一、现象：磁盘随机写打满，但 CPU 和 buffer pool 都很闲 去年给一套埋点落库系统做性能治理。核心表 "t_event_track"（约 2.3 亿行，单表含 6 个二级索引约 31GB，InnoDB，MySQL 8.0.34
一、现象与背景：批量导入 45 分钟，线上写入 QPS 掉了 92% 先给结论："INSERT ... SELECT" 在 "innodb_autoinc_lock_mode=1"（MySQL 5.1+ 默认值）下会拿表级 autoinc
【背景】 我负责一张 800 万行的订单宽表（InnoDB, MySQL 8.0.32），带 6 个二级索引。业务上每天约 30% 的行会被批量 UPDATE status 字段，持续一个月后观察到查询性能明显退化。 【现象】 1. SHO
背景 生产环境 MySQL 8.0.36，InnoDB，一张订单流水表 "t_order_flow" 约 3.2 亿行，".ibd" 文件 528GB，"SHOW TABLE STATUS" 显示 "Data_length" 约 78GB—
【背景】MySQL 8.0.32 / InnoDB，单库 32C/128G，innodb_buffer_pool_size=64G。日志明细表 log_event 约 3 亿行，PK=id（自增），索引 idx_ct (create_tim
背景：MySQL 8.0.32 / InnoDB，单主单从，主库承载支付清结算，核心表 t_settle_record 约 2.8 亿行，innodb_purge_threads=4，隔离级别 REPEATABLE READ。业务方有一个凌
«结论先行："INSERT ... ON DUPLICATE KEY UPDATE"（下称 ODKU）是"写法上最方便"的幂等手段，但它把"唯一索引冲突检查"和"UPDATE"塞进同一个事务、同一把行锁里完成，在高 QPS + 高重复率场景
«结论先行：InnoDB 的主键是聚簇索引的物理顺序，主键的随机性直接决定写入是顺序 IO 还是随机 IO。把 UUID v4 换成雪花 ID，同样的批量写入 P99 从 1.8s 降到 52ms，收益 35 倍——这不是"ID 格式"问题
背景：MySQL 8.0.36 / InnoDB，隔离级别 REPEATABLE READ。用户地址表 user_address，PK=id (bigint auto)，二级索引 idx_user (user_id bigint, addr
一、现象：一条"写入"接口，把磁盘 IO 打到 92% 先说结论：这次写入慢，不是慢 SQL、不是连接池、也不是网络，而是"主键用 UUID 导致 InnoDB 随机写 + 页分裂"。把主键换回自增后，同一台机器、同一份流量，写入 P99
【背景】 MySQL 8.0.32 / InnoDB，单库承载订单查询与归档。核心表 t_order 约 8000 万行、数据文件 15.2GB（含二级索引约 22GB），innodb_buffer_pool_size=16GB（机器 64
«结论先行：buffer pool 命中率不是越高越好，buffer pool 也不是越大越好。命中率 99.7% 时 P99 依然可以打到 800ms，因为「命中」不等于「无代价」——一次冷读抖动可以把 LRU young list 冲刷
背景 MySQL 8.0.30，InnoDB，一台 64C / 256G 裸金属，承载 3 个业务库。核心库有一张 1.2 亿行的支付流水表 "t_pay_flow"（PK=id，二级索引 "idx_merchant_status"、"id
一、现象：写入 QPS 没变，P99 却从 6ms 飙到 11ms 去年 Q3 给一套支付清结算系统做性能治理。核心表 "t_settle_record"： - 规模：单表 2.8 亿行、InnoDB 16KB 页、MySQL 8.0.32
discussion
MySQL 事务隔离级别：RC 还是 RR？8 年 DBA 视角下我最纠结的一个默认值
背景： 做 DBA 这 8 年，我接手过的 MySQL 实例里，大约 60% 跑在默认的 REPEATABLE READ（RR），40% 被业务方或前任 DBA 调成了 READ COMMITTED（RC）。每次新团队来问我"隔离级别该用哪
背景：MySQL 8.0.36，InnoDB，REPEATABLE READ。一张 3200 万行的工单表 tickets，主键 id（自增），二级索引 idx_tenant_status (tenant_id, status, creat
一、现象：监控里那条「不致命」的曲线 先给背景。一套 MySQL 8.0.32 / InnoDB 的订单+账务系统，主库 "innodb_buffer_pool_size=32GB"、"innodb_purge_threads=4"、"in
一、现象与背景：连接数翻倍，接口反而更慢 先给结论：当瓶颈在 InnoDB 行锁排队时，把连接数加上去，QPS 会微涨、P99 会暴涨，因为新连接只是多排队的人，不是多干活的人。 具体场景：一个库存扣减服务，MySQL 8.0.32（16C
一、现象：一次机房断电，订单表少了 412 条 去年 11 月，一家电商客户机房突然断电（UPS 顶了 90 秒，但一台主机因内存吃紧提前 OOM 重启）。恢复后业务方发现：断电前 1 分钟内的下单里有 412 条「客户端收到 200、但订
«结论先行：在 InnoDB 里，往带唯一索引的表并发 INSERT，最常见的死锁根因不是「写写竞争」，而是 Duplicate Key 检查触发的 S 锁 + 间隙锁，叠加自增主键的插入顺序不一致，形成 AB-BA 环路。这个坑我踩了两次