MySQL

«结论先行：批处理事故里最隐蔽的一种，不是"某个任务写错了"，而是"一堆各自都没问题的任务，被塞进了同一个整点"。它们单独看每个都很快，叠在一起却把共享的磁盘 IO 打穿。这篇文章给一份我能直接抄的"错峰 + 闸门"做法。» 一、现象：00

背景 我负责一条订单事件分发链路：Kafka 3.6（3 broker，topic "order-event" 64 分区，峰值 12000 msg/s，日均约 3000 万条），消费组 16 实例（每实例 4 分区），下游是 MySQL

背景 MySQL 8.0.32，InnoDB，订单流水表 "t_order_flow" 约 2.4 亿行，按 "created_at" 做 RANGE 月分区（约 30 个分区），二级索引 "idx_merchant_time (merch

一、现象：磁盘随机写打满，但 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

【背景】 我在一个订单中心做慢查询治理，主库 MySQL 8.0.32（单主 16C64G，innodb_buffer_pool_size=48G），核心表 orders 约 2.2 亿行，二级索引 idx_uid_created (uid

«结论先行："utf8mb4_general_ci" 和 "utf8mb4_0900_ai_ci" 都是「utf8mb4」，但它们是两套不同的比较规则（collation）。跨库 JOIN 时 collation 不一致，要么直接报 "Il

【背景】 我在做一个 3 年经验的性能优化，最近帮一个内部团队复盘一个 Go 1.21 网关服务：4C8G 单实例，QPS 约 4k，链路是「网关 → MySQL（读写分离）+ Redis」。P50 稳定在 25ms，P95 在 60ms

背景 我负责一条埋点事件流管道：Kafka 16 分区（单 broker 3C 部署），消费组 8 实例，每实例起 4 个 worker 线程，按 partition 分片（即每个 partition 固定绑 1 个 worker，分区内严

«结论先行：MySQL 里最「安静」的杀手不是行锁，而是 MDL（Metadata Lock，元数据锁）——它不抢数据、不抢 CPU，但能让一张表的所有 DML 集体排队，连接池在 10 分钟内被打满，且 "SHOW PROCESSLIST

«结论先行：「加了索引」≠「走了快路径」。慢查询里相当一部分不是没索引，而是索引选择性差、没做成覆盖索引、或者优化器在回表成本和全表扫描之间选错了。我 3 年里被「明明有索引却慢」坑过不止一次，这次把三件事拆开量化讲清楚。» 一、现象与背景

背景 我在维护一套 MySQL 8.0.32 的订单系统，核心报表查询里大量使用 CTE（WITH ... AS）来组织多表关联逻辑。最近遇到一个反复出现的执行计划漂移问题，想请教社区有实际经验的 DBA。 现象 一条典型 SQL 结构如下

«结论先行：分区表不是"大表救星"，而是一笔用"跨分区查询更慢 + 唯一键受限 + 每月必维护"去换"分区裁剪快 + 删历史秒级"的交易。该不该做，取决于你的读写是否天然按时间切分。下面是一次真实的改造复盘，把收益和代价都摆到明面上算账。»

【背景】 我负责一张 800 万行的订单宽表（InnoDB, MySQL 8.0.32），带 6 个二级索引。业务上每天约 30% 的行会被批量 UPDATE status 字段，持续一个月后观察到查询性能明显退化。 【现象】 1. SHO

«结论先行：连接池里的"会话变量"是会跨业务复用的——任何一次 "SET SESSION"（sql_mode、time_zone、max_execution_time、character_set_*）如果不被显式复位，就会沿着这条连接污染下

一、现象：一条 2ms 的权限校验，突然飙到 103ms 去年 Q4 给一套电商后台做慢查询巡检。核心链路是「登录用户 → 拉菜单列表」，SQL 长这样： SELECT m.menu_id, m.menu_name, m.parent_id

背景 我负责一条埋点落库链路：Kafka → 自研消费者 → JDBC 批量 INSERT 写 MySQL 8.0（InnoDB，binlog_format=ROW，sync_binlog=1，innodb_flush_log_at_trx

背景 生产环境 MySQL 8.0.36，InnoDB，一张订单流水表 "t_order_flow" 约 3.2 亿行，".ibd" 文件 528GB，"SHOW TABLE STATUS" 显示 "Data_length" 约 78GB—

«结论先行：深分页慢的根因不是「数据多」，而是 MySQL 优化器对 "ORDER BY … LIMIT m,n" 的处理策略——它必须把排序结果完整物化（或走排序索引顺序扫描）到第 m+n 行才肯截断，前 m 行的扫描成本是纯浪费。把「页

结论先行：慢查询里有一类最「安静」的杀手，是隐式类型转换——它让 EXPLAIN 里的 "type" 从 "ref"/"range" 退化成 "ALL"、"key" 列直接变 "NULL"，而 SQL 里你根本看不出任何「错别字」。字段是