标签频道
索引
该标签下的文章、提问与讨论帖。
现象与背景：一次慢查询治理的实战 在我们团队接手的某日志审计系统中，核心表 "t_audit_log" 规模达到了 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业
结论先行 在 MySQL 8.0 多租户库中，执行计划漂移是一个常见但高风险的问题，尤其在租户之间隔离性不强时。 本文将讨论 FORCE INDEX、optimizer hint、改 SQL、加索引四条路的取舍，以及如何建立可落线的治理规则
现象或背景 我在一个 5 亿行级的订单库上做过两年慢查询治理，最深的一条体感是：80% 的慢 SQL 最后都靠索引收敛了，但真正让我睡不着的，恰恰是那 20%「建了索引也解决不了、或者建了索引本身成了事故」的场景。 先给一个具体的数：我们库
现象与背景：一次慢查询治理的实战 在我们团队接手的某日志审计系统中，核心表 "t_audit_log" 规模达到了 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业
背景 MySQL 8.0.32 / InnoDB，单主 32C/128G，"innodb_buffer_pool_size=64G"。核心表 "t_msg_log" 约 1.2 亿行，PK=id，二级索引 "idx_user_ts (use
【背景】 去年我负责一个 2000 万行的订单流水表（MySQL 8.0，InnoDB），一条报表查询 "SELECT ... WHERE tenant_id=? AND status IN (?,?) AND created_at > ?
【背景】 做了 15 年数据库设计，我见过 90% 的业务表都带一个 is_deleted 或 deleted_at 列。理由通常很简单：「万一要恢复呢」「审计需要」「产品说不能真删」。上线时它确实是 5 分钟的事——加一列、改个 WHER
【背景】 做了 15 年 DBA，慢查询治理是日常中的日常。但每次拉上开发一起看 slow log，第一句话永远是"加个索引吧"。这句话听起来没毛病——5 分钟搞定、开发不用改代码、风险最低。 但问题是：这个"第一反应"在很多场景下是错的，
【背景】 我在一个 5 亿行级的订单库上做过两年慢查询治理，最深的一条体感是：80% 的慢 SQL 最后都靠索引收敛了，但真正让我睡不着的，恰恰是那 20%「建了索引也解决不了、或者建索引本身成了事故」的场景。 先给一个具体的数：我们库里一
【背景】 我是 DBA，3 年经验，主要做数据库设计与慢查询治理。主库 MySQL 8.0.32（社区版，InnoDB，单主 16C64G，innodb_buffer_pool_size=32G），核心业务表 "t_report_src"
【背景】 做了 5 年 DBA，慢查询治理是每周的固定动作。但每次性能评审，团队都会撞上同一个问题："这条 SQL 慢，我们到底该干嘛？" 答案从来不是唯一的——改 SQL 写法、加索引、拆表分库、加缓存、换引擎……每条路都有成本，每条路都
背景 我做了 15 年大数据平台，前 5 年在 DBA 团队，后面一直做数据仓库与 OLTP 混合场景。一个观察：慢查询报警一响，开发同学（甚至不少 DBA）的第一反应就是"加个索引"。快、简单、当天下线、不用改代码。 但真实场景里，"加索
背景 我负责一套 SaaS 计费系统，主库 MySQL 8.0.32（InnoDB，16C64G，"innodb_buffer_pool_size=48G"），核心表 "t_billing_item" 约 1.8 亿行。表上有 5 个二级索
背景：我们有一张 5.2 亿行的订单表（InnoDB，单主 MySQL 8.0.35，16C128G），日均写入 QPS 约 2000，读 QPS 约 8000。现需新增复合索引 idx_uid_status_created (uid, s
背景先说清楚：我这边一张 InnoDB 流水表 1.5 亿行，业务方临时要加一个二级索引 + 一个 NOT NULL 默认值的字段，要求「不停机、对线上 P99 影响可控、可回滚」。这种需求在大数据平台里太常见了，但每次拉群对齐，方案都打架
一、现象：「更安全」的工具反而更慢、更贵 去年给一套 ERP 系统做索引补建。核心表 "t_voucher_entry"（凭证分录表）规模：5280 万行、单表 11.7GB、InnoDB、MySQL 8.0.36、8C16G 云主机、SS
做了 8 年 DBA，慢查询治理几乎是日常。每次线上慢查询告警一响，我拉群拉人，第一句话经常被问的是"要不要加个索引"。但我越来越觉得，"加索引""改 SQL""改架构"这三条路各有各的适用边界，选错了代价不小。 我见过太多团队把"加索引"
«结论先行：「加了索引」≠「走了快路径」。慢查询里相当一部分不是没索引，而是索引选择性差、没做成覆盖索引、或者优化器在回表成本和全表扫描之间选错了。我 3 年里被「明明有索引却慢」坑过不止一次，这次把三件事拆开量化讲清楚。» 一、现象与背景
背景： 带团队做表设计这 15 年，被业务方和开发问得最多、也最容易当场吵起来的一个问题，就是「这张表要不要加个 deleted 字段做软删除？」。我的体感是：几乎每个团队都有软删除，但很少有人能清楚说出「为什么加、加在哪些表、索引怎么配套
«结论先行：深分页慢的根因不是「数据多」，而是 MySQL 优化器对 "ORDER BY … LIMIT m,n" 的处理策略——它必须把排序结果完整物化（或走排序索引顺序扫描）到第 m+n 行才肯截断，前 m 行的扫描成本是纯浪费。把「页
已经到底了
文
标题
摘要