An overview of how we investigated and solved the issue of some Kubernetes Pods running MySQL starting up and shutting down slower than other similar Pods with the same data set.

大佬前几天来自生产上的一个问题，又涨知识了，今天拿来分享给大家。

本文主要介绍去哪儿网DBA团队如何通过抓包、解析MySQL协议，获取数据库全量访问日志，解决了“谁动了我的数据”问题。

本文通过讲述一个数据不一致问题的定位原因和解决问题的过程，展示了MySQL改表工具ptosc在主从数据同步中的妙用。

我们动用 perf，来追踪打开句柄的系统调用。

从 MySQL 8.0.4 开始，默认身份验证插件从 mysql_native_password 更改为 caching_sha2_password。

因为机房搬迁，堡垒机集群需要迁移到新的网段，我们需要批量修改 MySQL 上这些账号的网段地址。下面我们研究一下应该怎么修改。

本文主要是通过对PFS引擎的内存管理的源码的阅读，解读PFS内存分配及释放原理，深入剖析其中存在的一些问题，以及一些改进思路。

在我们的开发过程中，经常会在一个项目中使用多种数据库系统。在一些特定场景下，我们希望把数据从一种数据库，同步到另一种异构的数据库，以便进行数据分析统计、完成实时监控、实时搜索等功能。这个异构数据源同步的过程称为Change Data Capture（变化数据捕获）。

我们本文讨论的是Source为MySQL、Target为ElasticSearch的场景下，进行增量和全量同步操作过程。众所周知，MySQL数据库凭借其性能卓越、服务稳定、开放源代码、社区活跃等因素，成为当下最流行的关系型数据库，但是在数据量级较大或涉及到多表操作时，亦或是需要根据地理位置进行查询时，MySQL通常不能给我们很好的支持。

为了解决MySQL查询缓慢、无法查询的问题，我们通常采用ElasticSearch等进行配合检索。在传统方式中，将MySQL同步数据到ElasticSearch通常采用的是双写、MQ消息等形式，这些形式都存在着耦合高、性能差、丢失数据等风险。

所以我们需要探索出一套对业务无侵入的MySQL同步至ElasticSearch异构数据库的解决方案。本文将分别从增量同步、全量同步两个层面进行探讨。

文章通过MySQL官方文档和MySQL源码两个方面，分析了MySQL主从复制延迟参数Seconds_Behind_Master是如何计算的。

本篇介绍子查询、分区表和JOIN的复杂转换过程。

用量化的思维解决慢查询。

一般来说讲，提到数据拆分，总归可以归结为两个层面：一是垂直拆分，二是水平拆分。这里我们来讨论下垂直拆分。

MySQL 配置文件和 mysqld.service 中都声明了可打开的最大文件数时，哪个在生效？

在日常开发工作中，我们几乎需要天天与数据库打交道，作为一名只会CRUD的SQL BOY，除了每天用mybatis-generator自动生成DAO层代码之外，我们几乎不用去care数据库中如何处理并发请求，但是突然某一天MYSQL数据库告警了，出现了死锁，我们的内心慌的一匹，不禁想问：这不就是个普通查询吗，咋还锁起来了？

为了避免慌乱的表情被主管捕捉到，我们需要提前了解一下数据库中到底有哪些锁。

在MySQL中，其实将锁分成了两类：锁类型（lock_type）和锁模式（lock_mode）。

锁类型描述的锁的粒度，也就是把锁具体加在什么地方；而锁模式描述的是到底加的是什么锁，是读锁还是写锁。锁模式通常和锁类型结合使用。

本文重点介绍了下优化器的基于规则的其中一部分优化，更多的偏重于SQL中的基本操作符。