在之前的文章「简单了解InnoDB底层原理」聊了一下MySQL的Buffer Pool。这里再简单提一嘴，Buffer Pool是MySQL内存结构中十分核心的一个组成，你可以先把它想象成一个黑盒子。
主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。
2 如何改善关系型数据库的性能。（《MySQL必知必会》P227）备份数据库和清除垃圾数据。
首先，InnoDB会判读缓冲池里是否存在 id = 1 这条数据，如果不存在则从磁盘中加载到缓冲池中，而且还会对这行数据加独占锁，防止多个sql同时修改这行数据。
上篇文章说了acid四个事务的特性，原子性保证要不两个sql一起执行，要么不执行，隔离性，两个事务之间必须互不干扰，一致性，两边的数据必须保持一致，可以说一致性的前提是原子性和隔离性必须正常，但原子性和隔离性都正常，就能保证一致性吗？并不是，还必须满足其他一些约束，比如金额不能为负数。持久性就是必须持久化到磁盘才算事务成功。
这是一条很简单的更新SQL，从MySQL服务端接收到SQL到落盘，先后经过了MySQL Server层和InnoDB存储引擎。
当客户端A检查还有一张票时，将票卖掉，还没有执行更新数据库的时候，客户端B检查了票数，发现大于0，于是又买了一次票。然后客户端A将票数更新回数据库。于是就出现了同一张票被卖了两次的情况。
XA，2PC，two-phase commit protocol。 两阶段事务提交采⽤的是 X/OPEN 组织定义的DTP 模型所抽象的
MySQL 为我们提供了分布式事务解决方案，在前面的内容中 聊一聊分布式事务的解决方案 提到过 binlog 的同步，其实是 MySQL XA 规范的一个应用，那么 XA 规范是如何定义的，具体又是如何应用的呢？
XA，2PC，two-phase commit protocol，两阶段事务提交采⽤的是 X/OPEN 组织定义的DTP 模型所抽象的：
今天想和大家聊一聊 MySQL 中的 redo log，其实最早我是想聊两阶段提交的，后来想想可能有小伙伴还不了解 binlog，所以就先整了一篇 binlog： 手把手教你玩 MySQL 删库不跑路，直接把 MySQL 的 binlog 玩溜！ MySQL删库不跑路（视频版） binlog 大家懂了之后，接下来还差个 redo log，redo log 大家也懂了，那么再讲两阶段提交相信小伙伴们就很容易懂了，咱们一步一步来。 1. 谁的 redo log 学习 redo log，我觉得首先要搞明白一个问
数据的一致性和完整性对于在线业务的重要性不言而喻，如何保证数据不丢呢？今天我们就探讨下关于数据的完整性和强一致性，MySQL做了哪些改进。
为了和前一篇文章介绍的场景区分开，我们用两个虚构小故事把两种场景放在一起作个对比。
明显不会，磁盘IO太慢了，如果每个请求过来 MySQL 都要写磁盘，磁盘肯定扛不住。
在上一篇《面试官：你说说一条查询SQL的执行过程？》中描述了Mysql的架构分层，通过解析器、优化器和执行引擎完成一条SQL查询的过程，那这一篇续上继续说明一条更新SQL的执行过程。
爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的处理。擅长数据库故障处理。对数据库技术和 python 有着浓厚的兴趣。
在使用MySQL数据库时，有时会出现ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 这样的报错。而在一个事务中，如果其中一条sql执行时出现此报错，对本事务的其他脚本是否有影响呢，后面如果执行commit操作，报错之前语句的结果是否成功呢？这个结果与隔离级别以及innodb_rollback_on_timeout参数设置有关。
由于每天起的太早，所以中午必须要午休，否则无法保证下午的工作状态。正在午休时，电话响起，一阵急促的声音，“看看咱们的message 系统，短信发不出去了，经销商无法登陆 ACS 系统了。“已经有客户 complain了。
看到博客园一位园友写了一篇文章，其中的观点是，要想高性能，需要尽量：避开网络开销（IO），避开海量数据，避开资源争夺。对于这3点，我觉得很有道理。所以也想谈一下，CQRS架构下是如何实现高性能的。
很多新入职的小朋友可能和现在的我一样，对数据库的了解仅仅停留在建库建表增删改查这些操作，日常工作也都是用封装好的代码，别说底层原理了，数据库和系统之间是如何工作都不是很懂。
本文咱们将通过按照Tomcat、按照MySQL、安装Redis这三个实战安装，来熟悉在docker中怎么安装软件，咱们使用端口映射，及数据卷的使用场景
http://www.cnblogs.com/netfocus/p/4055346.html
前段时间，公司内部遇到了一个问题，就是我们创建的同一批任务，别分配给了不同的实例去执行，导致线上的结果出现问题。
之前的文章简单的介绍了 MySQL 的事务隔离级别，它们分别是：读未提交、读已提交、可重复读、串行化。这篇文章我们就来探索一下 MySQL 事务隔离级别的底层原理。
MySQL系列会通过引擎、索引、事务、锁来说明，这篇文章讲讲基本的概念和引擎的区别。
转载于:https://www.cnblogs.com/2woods/p/9394614.html
redo是引擎层的日志，而且是InnoDB特有的。InnoDB的redo log是有固定大小的，比如可以配置为 一组4个文件（logfile-1，logfile-2，logfile-3，logfile-4），每个文件的大小是1GB，那么它总共可以记录4GB的操作。一个环状循环结构，从头开始写，写到末尾又回到开始循环写。
XA 是由 X/Open 组织提出的分布式事务规范，XA 规范主要定义了事务协调者（Transaction Manager）和资源管理器（Resource Manager）之间的接口。
看到percona发了篇Do Not Upgrade to Any Version of MySQL After 8.0.37. 说是mysql新版本有BUG.
当数据库中一个事务A正在修改一个数据但是还未提交或者回滚时，另一个事务B 来读取了修改后的内容并且使用了，然后事务A进行了提交，此时就引起了脏读。
innodb 为了提高磁盘I/O读写性能，存在一个 buffer pool 的内存空间，数据页读入会缓存到 buffer pool，事务的提交则实时更新到 buffer pool，而不实时同步到磁盘（innodb 是按 16KB 一页同步的，一事务可涉及多个数据页，实时同步会造成浪费，随机I/O）。事务暂存在内存，则存在一致性问题，为了解决系统崩溃，保证事务的持久性，我们只需把事务对应的 redo 日志持久化到磁盘即可（redo 日志占用空间小，顺序写入磁盘，顺序I/O）
众所周知数据库连接的过程，但是最近面试的人(菜面菜)，都说用的SSM框架，但是我问了一下，mybatis是怎么连接上mysql的，基本上都会说：配置好的，直接用了，今天我来抛砖引玉一下，欢迎拍砖！
在前一阵子，大哥问过我：”你知道MySQL的原子性是怎么保证的吗“。我懵逼了，MySQL怎么保证原子性？我不会啊。
失踪人口终于更新了答案，我保证会更新完毕的！想直接看题目的小伙伴可以来这个传送门：应粉丝要求，请假一周，面了9家深圳非外包初级开发，只为刷一刷真题（文末有福利）
如果你选mysql数据库作为数据持久化的工具，那么就需要一个合理的日志配置，这样有助于排错和数据备份及恢复！
上文《MySQL数据被误删怎么办？》介绍了MySQL在故障或者误删数据后，可以通过备份+binlog的方式进行数据恢复。但是，当备份文件和binlog都丢失了呢？所以单节点是不可靠的，为了避免单节点故障带来的数据丢失以及MySQL服务的可用性，生产环境通常都是采用高可用或者集群模式。而在这背后则离不开主从复制技术，所以本文对主从复制的原理和操作展开介绍，从而全面了解这一技术。
摘要：上一集我们一起入门学习了git的基本概念和git常用的操作，包括提交和同步代码、使用分支、出现代码冲突的解决办法、紧急保存现场和恢复现场的操作。学会以后已经足够我们使用Git参加协作开发了，但是在开发的过程中难免会出错，本文主要介绍版本控制的过程中出错了的场景，以及Git开发的一些技巧，让我们用的更流畅。
本篇是咸鱼日常撸视频的时候记录的一些代码实例，可以直接运用到项目中但是有些代码的可用性没有那么好，旨在分享思路，不喜勿喷~
持久化存储有3中基础的存储机制：文件、数据库(关系型和非关系型)以及一些混合类型。文件存储不适合大型项目，需要使用数据库存储，MySQL是目前持久化存储中最流行的解决方案。
基于 Hive 的离线数仓往往是企业大数据生产系统中不可缺少的一环。Hive 数仓有很高的成熟度和稳定性，但由于它是离线的，延时很大。在一些对延时要求比较高的场景，需要另外搭建基于 Flink 的实时数仓，将链路延时降低到秒级。但是一套离线数仓加一套实时数仓的架构会带来超过两倍的资源消耗，甚至导致重复开发。
一个6亿的表a，一个3亿的表b，通过外间tid关联，你如何最快的查询出满足条件的第50000到第50200中的这200条数据记录。
Git 命令对于程序员的你来说再熟悉不过，但是发现好多小伙伴都是会一些基本的提交流程，当遇到问题的时，查到的命令还不敢用，总是请教组里那几个精通 Git 的小伙伴。本文对 Git 使用过程中常出现的问题进行总结并且对 Git 的一些误区概念说明了一些，看完后记得自己尝试下，希望你也能成为组里被请教的那 个 Git 小能手。
不要小看一条 update 语句，在生产机上使用不当可能会导致业务停滞，甚至崩溃。
下面我们介绍一下脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）这三类并发问题，以及每种问题出现的原理及场景。
1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中；
2023 年某一天周末，新手程序员小明因为领导安排的一个活来到公司加班，小明三下五除二，按照领导要求写了一个跑批的数据落库任务在测试环境执行 ，突然间公司停电了，小明大惊，“糟了，MySQL 还在跑任务，会不会因为突然断电，导致数据库崩了”。
还是先在粉板上记一下方便。如果掌柜没有粉板，每次记账都翻账本，效率是不是低死啦？ MySQL也有这个问题，若每次更新操作都写进磁盘，然后磁盘也要找到对应记录，然后再更新，整个过程IO成本、搜索成本都很高。 何解？采用类似酒掌柜粉板的思路。
这期给大家分享一个读者给我分享的一个关于 MyBatis 的“编程小技巧”，说真的，这骚操作，直接把我看得一愣一愣的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
