数据库

背景 我做了 10 年大数据平台，最近半年在两个团队里反复撞见同一个"建完之后才暴露"的问题：物化视图、Redis 缓存、StarRocks 物化表都建好了，P99 从 3s 降到 30ms，看起来很完美；结果运营第二天来问"昨天 14:0

背景 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

做了 8 年 DBA，慢查询治理几乎是日常。每次线上慢查询告警一响，我拉群拉人，第一句话经常被问的是"要不要加个索引"。但我越来越觉得，"加索引""改 SQL""改架构"这三条路各有各的适用边界，选错了代价不小。 我见过太多团队把"加索引"

一、现象与背景：批量导入 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 年大数据平台，最近半年在不同团队里反复撞同一个问题：业务方说「就一个 select count(*)，跑在主库上 200ms 就完了」，DBA 说「主库是交易的命脉，报表这种长 SQL 进来就是灾难」。争论到最后往往不是技术

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

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

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

背景： 带团队做表设计这 15 年，被业务方和开发问得最多、也最容易当场吵起来的一个问题，就是「这张表要不要加个 deleted 字段做软删除？」。我的体感是：几乎每个团队都有软删除，但很少有人能清楚说出「为什么加、加在哪些表、索引怎么配套

【背景】 我负责一张 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

背景： 我做了 8 年大数据平台，最近复盘一次事故：凌晨一个 BI 报表任务扫了 40GB 未命中的分区，把共享查询引擎的内存打爆，连带拖垮了两条在线服务链路。事后我们上了「查询级超时 + 资源配额 + 优先级队列」，但团队内部吵了一架：数

背景 生产环境 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 行的扫描成本是纯浪费。把「页

背景 做了 5 年 DBA，被问得最多的一句话是："这条 SQL 慢，你给加个索引不就完了？" 但换个场合，领导又会说："DBA 是要兜底整个库的性能的。" 这两句话同时成立，就变成 DBA 一个人既当裁判又当运动员：既要劝业务方改写法，又

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