MySQL 主从复制延迟持续扩大：从现场取证到并行复制治理的排查实践
## 适用场景 本文适用于 MySQL 8.0 或已启用 GTID 的 MySQL 5.7 主从/主备架构：监控显示 `Seconds_Behind_Source` 持续增长，报表、读库或故障切换的恢复点开始不可接受。目标是先确认延迟真实原因，再在不破坏复制一致性的前提下恢复追平。 ## 现象描述 一次订单促销后
Tag
#MySQL
包含这个标签的文章。
MySQL binlog 突增吃满磁盘：从定位大事务到安全清理的排查实践
## 适用场景 MySQL 主库所在分区持续增长，`/var/lib/mysql` 已接近 100%，业务开始出现写入失败、事务提交变慢，甚至因为磁盘写满而触发只读保护。检查目录后发现大量 `mysql-bin.000xxx` 文件，但不能直接删除：binlog 仍可能被复制从库、增量备份或审计流程使用。 本文适用
Django 生产迁移卡住：从锁等待取证到可回滚发布的排查实践
## 适用场景 生产环境执行 `python manage.py migrate` 后长时间没有结束，应用发布流水线被阻塞；或者迁移最终报出 `Lock wait timeout exceeded`、`OperationalError`。这类问题常见于 Django + MySQL/InnoDB：迁移本身很短，却在等
MySQL 死锁频发：从现场取证到有边界重试的排查与治理实践
## 适用场景 业务接口偶发返回 `Deadlock found when trying to get lock`（错误码 1213），订单、库存、账户余额或状态流转等事务写入失败；重试后通常成功，但高峰期错误数明显上升。本文以 InnoDB 为例，给出一套可在生产环境执行的取证、定位和治理流程。 死锁不是数据库“
MySQL 联合索引顺序不匹配导致慢查询的排查与优化实践
## 适用场景 业务表按租户、状态和创建时间查询列表。数据量从几十万增长到千万级后，接口 P95 延迟突然升高；应用监控中数据库耗时占比明显增加，但 CPU 和磁盘利用率并不一定很高。 本文以常见的订单列表为例，说明如何确认“建了索引却没有用好”的联合索引问题，并在不影响线上写入的前提下完成优化。 ## 现象描述
MySQL 临时表落盘导致磁盘占用和查询延迟升高的排查实践
## 适用场景 本文适用于线上 MySQL 出现以下情况： - 接口偶发变慢，慢查询集中在 `ORDER BY`、`GROUP BY`、`DISTINCT`、复杂分页或报表 SQL 上。 - 数据库实例的磁盘使用率短时间上涨，过一段时间又自动回落。 - `tmpdir` 所在分区 IO 使用率升高，甚至出现 `No
MySQL 元数据锁导致 DDL 卡住和业务请求堆积的排查实践
## 适用场景 这篇文章适用于 MySQL 5.7、MySQL 8.0 或兼容 MySQL 协议的数据库中，执行 `ALTER TABLE`、`CREATE INDEX`、`DROP INDEX`、`TRUNCATE TABLE` 等 DDL 时长时间不返回，同时业务侧出现接口变慢、连接数升高、写入卡住等问题的场景。
MySQL Too many connections 线上连接打满排查实战
## 适用场景 本文适用于线上业务访问 MySQL 时突然出现连接失败、接口大量报错、应用日志出现 `Too many connections`、连接池获取连接超时，或者监控中 MySQL `Threads_connected` 快速逼近 `max_connections` 的场景。 这类问题通常不是简单把 `ma
Django 表结构修改
## 只是添加表字段 在修改完models.py后，再重复执行` python manage.py makemigrations`和`python manage.py migrate`即可。 ## 要更改表结构 需要删除第一次执行迁移生成的`001_initial.py`文件、数据库中对应的表以及数据库中`dja
Zabbix MySQL分区表配置
在使用zabbix的过程中，随着时间的推移，数据库中的历史数据会越来越多，会发现打开页面，查询数据等会变慢。zabbix 自带的 housekeeper会定时清理（默认一小时清理一次）旧的数据。不过在 housekeeper清理过中，会导致数据库负载极具增加。这里介绍另外一种办法，就是对几个历史数据表做分区表（part