本文通过讲述一个数据不一致问题的定位原因和解决问题的过程，展示了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中的基本操作符。

在生产中一般发生运行问题，可以翻翻 error 日志，大部分都能解决。有的时候数据库突然宕机重启，此时我们在 error 日志中会发现"This could be because you hit a bug"，然后打了一堆看不懂的堆栈。这时候如果拿着碰到BUG的结论交差，多半会被应用一顿暴击输出：有证据没，这个 bug 怎么出现的，官方怎么修的，在什么版本修的。那么接下来，我将根据现有 error 日志报错中的堆栈信息，找到详细的 BUG 修复记录。

基于MySQL BinLog日志的同步系统，将MySQL中的数据实时同步到其他数据库（Redis、ElasticSearch、HBase），简单配置即可完成数据的异构存储。

最近组内同学遇到一个问题，说数据库被业务打死了，无响应，只好用 kill -9 pid 杀掉，然后重启，幸好此时的数据库角色是从库，影响不大。同学自述，在杀掉重启的时候，心里默念，千万别启不来啊，这个库的数据量有点大，快要达到 4T 了。做运维的人都知道，事情就不能念叨，一念叨，这事儿就准发生。这次也不例外，确实是出现了。现象是长时间启动不了，基本卡死状态。