故事背景 最近我们遇到了一个看似简单但背后很有坑的需求：在千万级订单表中新增一个业务字段。需求来自隔壁项目组，他们需要这个字段做一些统计分析。 从开发角度看，这事很常见，**新增字段嘛，直接ALTER

Explain总览图 这篇文章主要看图 Explain是啥 1、Explain工具介绍 使用EXPLAIN关键字可以模拟优化器执行SQL语句，分析你的查询语句或是结构的性能瓶颈， 在 select 语

前言： MySQL 死锁是一种常见的问题，指两个或多个事务互相持有对方所需要的资源，并且都在等待对方释放，导致所有事务都无法继续执行。以下是 MySQL 死锁的排查方法、预防手段以及解决方式的详细解析

本文主要介绍了case函数在MySQL中用法和注意事项；使用场景包括了case在列字段处理，行转列等；特别提到了case when在某些场景下可用于SQL语句的优化。

亿级别大表拆分 —— 记一次分表工作的心路历程 笔者是在两年前接手公司的财务系统的开发和维护工作。本文介绍了一个亿级别大表拆分的心路历程

项目开发中，我们的数据库数据越来越大，随之而来的是单个表中数据太多。当出现这种情况时，我们可以考虑分表。 分表倒是好说，但是怎么平滑上线让用户无感知呢？

水平拆分表就是按照表中的记录进行分片，那么具体应该怎么进行拆分，涉及到数据归并要怎么进行处理，原来的join语句还能用吗？

MySQL库表设计为什么不建议使用TEXT类型 背景 在需求中有一段不确定长度的序列化数据，后端同学的库表设计中将这个字段设计为VARCHAR(2000)类型。 因此我产生了一个疑问：既然不确定长度，

大家好，我是苏三，又跟大家见面了。 前言 大表优化是一个老生常谈的话题，但随着业务规模的增长，总有人会“中招”。 很多小伙伴的数据库在刚开始的时候表现良好，查询也很流畅，但一旦表中的数据量上了千万级，