标签频道
MySQL
该标签下的文章、提问与讨论帖。
一、现象：磁盘随机写打满，但 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
article
加了索引还是慢：索引选择性、覆盖索引与回表成本的一次量化拆解
«结论先行：「加了索引」≠「走了快路径」。慢查询里相当一部分不是没索引，而是索引选择性差、没做成覆盖索引、或者优化器在回表成本和全表扫描之间选错了。我 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 里你根本看不出任何「错别字」。字段是
【背景】MySQL 8.0.32 / InnoDB，单库 32C/128G，innodb_buffer_pool_size=64G。日志明细表 log_event 约 3 亿行，PK=id（自增），索引 idx_ct (create_tim
discussion
大表 DDL 在线变更：双写对账 vs 锁表停机，你们团队到底怎么选？
【背景】 社区里连接池、超时重试、异步化都聊得挺透了，但有一个更「硬」的问题我很少看到被正面讨论：一张千万级甚至亿级行的大表，要加列、改索引、改类型，你的团队到底怎么落地？ 我自己踩过的场景：一张 8000 万行的订单流水表，业务要求「加一
一、现象：一条"看起来很简单"的查询，P99 卡在 1.8s 去年我们迁移订单中心到 MySQL 8.0.32，主表 "orders" 约 2.1 亿行，单表 190GB。客服后台有一个高频接口：查某用户最近的 20 条订单： SELECT