大家好，我是田哥 今天来和大家分享MySQL的三个日志文件，可以说 MySQL 的多数特性都是围绕日志文件实现，而其中最重要的有以下三种： redo 日志 undo 日志 binlog 日志 比如更新语句的流程会涉及到 undo log（回滚日志）、redo log（重做日志） 、binlog （归档日志）这三种日志： undo log（回滚日志） ：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。 redo log（重做日志） ：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复； binlog （归档日志） ：是 Server 层生成的日志，主要用于数据备份和主从复制；

130 Technology lddgo Shared on 2022-11-22

主库的职能是负责写，从库主要是负责读,可以建立读库集群,通过读写职能在数据源上的隔离达到减少读写冲突、释压数据库负载 、保护数据库的目的 。在实际的使用中,凡是涉及到写的部分直接切换到主库，读的部分直接切换到读库，这就是典型的读写分离技术。 本文将聚焦读写分离，探讨如何实现它。

132 Technology lddgo Shared on 2022-11-11

电商业务场景，随着平台订单规模的日益增长，订单现有的存储已经没办法支撑后面业务的发展。在得物五彩石项目的时候就对订单进行了分库分表的拆分，为了解决分库分表后卖家维度的查询问题，单独创建了一个卖家维度的订单库。 目前订单分为买家和卖家两个库，卖家库的数据是通过监听买家库binlog异构出来的一个库。现在订单主要有两张表，分别是订单的主表和子表。 在异构的逻辑中，我们会对这两张表的binlog消息进行处理，异构成我们的卖家订单表。在监听到插入的消息时，只会处理子表的插入消息，其余需要补充的主订单表数据直接查询主表。

131 Technology lddgo Shared on 2022-11-01

最近业务系统生产环境的IDB在执行事务的过程中出现了ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 异常。通过相关资料的查询和了解，发现出现这个问题的原因是产生了悬挂事务。整个排查的过程也比较困难，因此和大家分享下排查问题的经过。如果文中有错漏的地方，欢迎大家指正。

175 Technology lddgo Shared on 2022-09-19

最近使用sysbench测试MySQL，由于测试时间较长，写了一个脚本按prepare->run->cleanup的顺序在后台跑着。跑完后察看日志发现一个问题，MySQL服务的错误日志中出现多条类似以下信息的报错：

293 Technology lddgo Shared on 2022-09-07

订座在现实生活中是一种很常见的场景，比较常见的有火车票席位选择，电影院席位选择等等。那么如何实现订座功能呢？应用程序可能有很多种不同的实现方式，当然，肯定离不开数据库。这里将介绍一种纯数据库的实现方式。

165 Technology lddgo Shared on 2022-09-07

本文（有码慎入）主要介绍Linux任务调度相关的发展历史和基本原理。多年以来，内核界的黑客们一直着力于寻找既能满足高负载后台任务资源充分利用，又能满足桌面系统良好交互性的调度方法，尽管截至到目前为止仍然没有一个完美的解决方案。本文希望通过介绍调度算法的发展历程，因为任务调度本身不是一个局限于操作系统的话题，包括数据库，程序语言实现等，都会与调度相关。本文在介绍过程中，会引用Linux的代码实现作为说明，同时阐述其中的一些趣闻轶事。

158 Technology lddgo Shared on 2022-09-07

MySQL可以使用OpenSSL或yaSSL/wolfSSL进行编译，这两者都支持基于OpenSSL API的加密连接。在5.7版本，我们知道默认情况下MySQL Community Edition用的SSL库是yaSSL，而在8.0版本，MySQL Community Edition用的是OpenSSL。那么SSL加密对性能有什么影响呢？这两个SSL库在性能上又到底有多大差别呢？我们接下来进行一些测试并进行分析。

157 Technology lddgo Shared on 2022-09-07

近日接报某实例一个datetime字段主从数据不一致，其它数据暂未发现异常。第一反应可能是人为修改，如果用户有高权限帐号，是可以做到的，但检查所有帐号权限排除了这种可能。难道有黑客入侵？神经一下绷紧，仔细排查各种系统状态，很快也排除了这种可能。同时分析业务类型，有问题的值都是从机都是比主机少一秒，时间戳被改小一秒不能带来任何收益，被非法篡改的可能性基本排除。

165 Technology lddgo Shared on 2022-09-07

近期，线上有个重要Mysql客户的表在从5.6升级到5.7后master上插入过程中出现"Duplicate key"的错误，而且是在主备及RO实例上都出现。以其中一个表为例，迁移前通过“show create table” 命令查看的auto increment id为1758609， 迁移后变成了1758598,实际对迁移生成的新表的自增列用max求最大值为1758609。用户采用的是Innodb引擎，而且据运维同学介绍，之前碰到过类似问题，重启即可恢复正常。

164 Technology lddgo Shared on 2022-09-07