cpxsxn的博客

MySQL 的主从复制是一种常见的数据复制机制，用于在多个 MySQL 数据库服务器之间同步数据。主从复制的基本原理是将一个主服务器（Master）上的数据更改复制到一个或多个从服务器（Slave）上。

我们前面介绍查询成本的时候经常用到一些统计数据，比如通过SHOW TABLE STATUS可以看到关于表的统计数据，通过SHOW INDEX可以看到关于索引的统计数据，那么这些统计数据是怎么来的呢？它们是以什么方式收集的呢？本章将聚焦于InnoDB存储引擎的统计数据收集策略。设计MySQL的大佬们给我们提供了系统变量innodb_stats_persistent来控制到底采用哪种方式去存储统计数据。

我们之前老说MySQL执行一个查询可以有不同的执行方案，它会选择其中成本最低，或者说代价最低的那种方案去真正的执行查询。对于InnoDB存储引擎来说，页是磁盘和内存之间交互的基本单位，设计MySQL的大佬规定读取一个页面花费的成本默认是1.0，读取以及检测一条记录是否符合搜索条件的成本默认是0.2。1.0、0.2这些数字称之为成本常数，这两个成本常数我们最常用到，其余的成本常数我们后边再说。

了解完了独立表空间的基本结构，系统表空间的结构也就好理解多了，系统表空间的结构和独立表空间基本类似，只不过由于整个MySQL进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页，所以会比独立表空间多出一些记录这些信息的页。因为这个系统表空间最牛逼，相当于是表空间之首，所以它的表空间 ID（Space ID）是0。

表空间是一个抽象的概念，对于系统表空间来说，对应着文件系统中一个或多个实际文件；对于每个独立表空间来说，对应着文件系统中一个名为表名.ibd的实际文件。大家可以把表空间想象成被切分为许许多多个页的池子，当我们想为某个表插入一条记录的时候，就从池子中捞出一个对应的页来把数据写进去。

在一个页中的查找在很多页中查找大部分情况下我们表中存放的记录都是非常多的，需要好多的数据页来存储这些记录。在没有索引的情况下，不论是根据主键列或者其他列的值进行查找，由于我们并不能快速的定位到记录所在的页，所以只能从第一个页沿着双向链表一直往下找，在每一个页中根据我们刚刚介绍过的查找方式去查找指定的记录。因为要遍历所有的数据页，所以这种方式显然是超级耗时的，如果一个表有一亿条记录，使用这种方式去查找记录那要等到猴年马月才能等到查找结果。

InnoDB为了不同的目的而设计了许多种不同类型的页，比如存放表空间头部信息的页，存放Insert Buffer信息的页，存放INODE信息的页，存放undo日志信息的页等等等等。本文聚焦的是那些存放我们表中记录的那种类型的页，官方称这种存放记录的页为索引（INDEX）页，鉴于我们还没有了解过索引是个什么东西，而这些表中的记录就是我们日常口中所称的数据，所以目前还是叫这种吧。

InnoDB是一个将表中的数据存储到磁盘上的存储引擎，所以即使关机后重启我们的数据还是存在的。而真正处理数据的过程是发生在内存中的，所以需要把磁盘中的数据加载到内存中，如果是处理写入或修改请求的话，还需要把内存中的内容刷新到磁盘上。而我们知道读写磁盘的速度非常慢，和内存读写差了几个数量级，所以当我们想从表中获取某些记录时，InnoDB存储引擎需要一条一条的把记录从磁盘上读出来么？

我们知道，对于使用InnoDB作为存储引擎的表来说，不管是用于存储用户数据的索引（包括聚簇索引和二级索引），还是各种系统数据，都是以页的形式存放在表空间中的，而所谓的表空间只不过是InnoDB对文件系统上一个或几个实际文件的抽象，也就是说我们的数据说到底还是存储在磁盘上的。但是各位也都知道，磁盘的速度慢的跟乌龟一样，怎么能配得上“快如风，疾如电”的CPU呢？所以InnoDB存储引擎在处理客户端的请求时，当需要访问某个页的数据时，就会把完整的页的数据全部加载到内存中，。

以此类推，如果之后事务id为200的记录也提交了，再此在使用READ COMMITTED隔离级别的事务中查询表hero中number值为1的记录时，得到的结果就是’诸葛亮’了，具体流程我们就不分析了。随着系统的运行，在确定系统中包含最早产生的那个ReadView的事务不会再访问某些update undo日志以及被打了删除标记的记录后，有一个后台运行的purge线程会把它们真正的删除掉。隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了；

如果该属性的值为 TRXUNDO ACTIVE，则意味着有一个活跃的事务正在向这个 Undo 页面链表中写入 undo 日志，然后再在 Undo Segment Header 中找到 TRX UNDO LAST LOG 属性,通过该属性可以找到本Undo 页面链表最后一个 Undo Log Header 的位置。我们现在知道一个事务在执行过程中最多可以分配4个 Undo 页面链表，在同一时刻不同事务拥有的 Undo 页面链表是不一样的，所以在同一时刻系统里其实可以有许许多多个 Undo 页面链表存在。

设计InnoDB的大佬认为同一个事务向一个Undo页面链表中写入的undo日志算是一个组，比方说我们上面介绍的trx 1由于会分配3个Undo页面链表，也就会写入3个组的undo日志；但是我们前面又强调过，同一个Undo页面要么只存储TRX_UNDO_INSERT大类的undo日志，要么只存储TRX_UNDO_UPDATE大类的undo日志，反正不能混着存，所以在一个事务执行过程中就可能需要2个Undo页面的链表，一个称之为insert undo链表，另一个称之为update undo链表;

我们说过事务需要保证原子性，也就是事务中的操作要么全部完成，要么什么也不做。这两种情况都会导致事务执行到一半就结束，但是事务执行过程中可能已经修改了很多东西，为了保证事务的原子性，我们需要把东西改回原先的样子，这个过程就称之为回滚（英文名：rollback），这样就可以造成一个假象：这个事务看起来什么都没做，所以符合原子性要求。从上面的描述中我们已经能隐约感觉到，每当我们要对一条记录做改动时（这里的改动可以指INSERT、DELETE、UPDATE），都需要留一手 —— 把回滚时所需的东西都给记下来。

有一个很不幸的事实就是我们的redo日志文件组容量是有限的，我们不得不选择循环使用redo日志文件组中的文件，但是这会造成最后写的redo日志与最开始写的redo日志追尾，这时应该想到：redo日志只是为了系统奔溃后恢复脏页用的，如果对应的脏页已经刷新到了磁盘，也就是说即使现在系统奔溃，那么在重启后也用不着使用redo日志恢复该页面了，所以该redo日志也就没有存在的必要了，那么它占用的磁盘空间就可以被后续的redo日志所重用。自系统开始运行，就不断的在修改页面，也就意味着会不断的生成redo日志。

max_connections 和 innodb_thread_concurrency

serverTimeZone的作用就是指定web服务器和mysql服务器的会话期间的mysql服务器时区，就是临时指定mysql服务器的时区。同理 golang 也有类似配置。// 在给创建时间赋值时，会把服务器所在时区的时间转换为 UTC 时间保存；// 而在获取数据时会把数据库里的创建时间当成 UTC 时区的，然后转换为 bean.DbEngine.TZLocation 时区的时间。

以 localhost 登陆，表示用 socket 登陆。

PostgreSQL快速入门 和 基本操作

【代码】制作 MySQL 镜像的 dockerfile以及 ENTRYPOINT 和 CMD 的区别。

➜ ~ mysql --ssl-mode=REQUIRED -ucpx -p 服务端没有开启 ssl。

2、where条件是在临时表生成好后，再对临时表进行过滤的条件。这时已经没有left join的含义（必须返回左边表的记录）了，条件不为真的就全部过滤掉，on后的条件用来生成左右表关联的临时表，where后的条件对临时表中的记录进行过滤。1、on条件是在生成临时表时使用的条件，它不管on中的条件是否为真，都会返回左边表中的记录。

tinyint(1) 和 tinyint(4) 中的1和4并不表示存储长度，只有字段指定zerofill是有用，如tinyint(4)，如果实际值是2，如果列指定了zerofill，查询结果就是0002，左边用0来填充。char是一种固定长度的类型，varchar则是一种可变长度的类型，它们的区别是：char(M)类型的数据列里，每个值都占用M个字节，如果某个长度小于M，MySQL就会在它的右边用空格字符补足．（在检索操作中那些填补出来的空格字符将被去掉）在varchar(M)类型的数据列里，每.

[root@dbs-test-rob tmp]# mkdir robertbackup[root@dbs-test-rob tmp]# xtrabackup --defaults-file=/etc/my.cnf --backup -uxxx -pxxxxxx -S/var/run/mysqld/mysqld.sock --slave-info --target-dir=/tmp/robertbackup xtrabackup: recognized server arguments: --datad

本期的着重点就不在MySQL架构图上，文章标题也给出了大家重点，就是要了解redo log、binlog。一、redo log第一步，创建一个表 user，主键是 id，下面是创建语句。CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(255) NOT NULL, age tinyint(4) NOT NULL, time int(11) NOT NULL, PRIMARY KEY (id)) ENGINE=Inn

[root@dbs-recover-dest mybackup]# pwd/root/mybackup[root@dbs-recover-dest mybackup]# [root@dbs-recover-dest mybackup]# lsfull_20210909210500.tar.gz[root@dbs-recover-dest mybackup]# mkdir mysql3306 ------step1------[root@dbs-recover-de

windows mysql(解压版)的单机多实例：D:\mysql-5.7.32-winx64-3307\bin>mysqld --initializeD:\mysql-5.7.32-winx64-3307\bin>D:\mysql-5.7.32-winx64-3307\bin>D:\mysql-5.7.32-winx64-3307\bin> 可以服务的形式启动，也可以只能每次手动启动D:\mysql-5.7.32-winx64-3307\bin>mysqld --i

备份命令：mysqldump --single-transaction --master-data=2 --hex-blob --set-gtid-purged=OFF -uinception -p -h172.25.206.228 xdbamp api > /tmp/api.sql Binlog 解析：mysqlbinlog --database archiver -vv --start-datetime='2021-09-01 12:35:00' --stop-datetime=

在 Django 的视图函数中有时需要保存前端传输过来的数据：包括文本文件和表情。这是在开发工单系统保存回滚 SQL 时遇到的问题。为了可以保存表情需要（不能用utf-8字符集在MySQL中存储4字节字符.）：更改MySQL数据库、表和列，以使用utf 8mb4字符集(只可从mysql 5.5开始使用) alter table db_task_progress modify name text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci COM

通过实例演示 replace into 和 insert into … on duplicate key update 的异同以及对 auto_increment 的影响： 话不多说，直接上代码# 创建一个测试表，其中列 code 上有唯一索引# 下面的测试均是指会发生冲突的情况：# replace into 的时候，如果 replace 语句的字段不全的话，则没出现的字段的值会被自动填充为字段类型的默认值# insert into ... on duplicate key update 的时候，

kill 会话的实现原理一、简单的过程梳理和列子二、kill的不同情况三、发起kill命令的线程四、 待杀死线程正在执行命令，如上的select的情况(非Innodb行锁等待情况)。五、 待杀死线程正在执行命令，如DML等待(Innodb行锁等待情况)，需要Innodb层唤醒，代码则继续。六、Innodb kill 逻辑触发阶段总结七、待杀死线程空闲状态正在等待命令的到来八、待杀死线程正在执行命令，MySQL层进行等待比如sleep命令，需要MySQL层唤醒，代码则继续。九、待杀死线程终止十、总结源码版

在和同事讨论 systemtap 的时候， 提到 performance_schema 里的 threads 表，只要 client 连接上 server之后，在该 session 里面执行的所有 SQL 都有共同的线程 ID:mysql> select processlist_id,thread_os_id from performance_schema.threads where processlist_info like 'select process%';+----------------

通过CONN_MAX_AGE优化Django的数据库连接：上周对我们用Django+Django-rest-framework提供的一套接口进行了压力测试。压测的过程中，收到DBA通知——数据库连接数过多，希望我们优化下程序。具体症状就是，如果设置mysql的最大连接数为1000，压测过程中，很快连接数就会达到上限，调整上限到2000，依然如此。Django的数据库连接：Django对数据库的链接处理是这样的，Django程序接受到请求之后，在第一访问数据库的时候会创建一个数据库连接,直到请求结束，

当用 Python 操作MySQL时，我们经常用的驱动是 mysql.connectorimport mysql.connectorfrom mysql.connector import InterfaceError, OperationalError这里需要强调的是：如果 SQL 执行的是 ALTER 操作，则当客户端程序走到 cursor.execute(sql) 后：如果因为 SQL 返回超时，客户端抛异常然后close cursor 和 conn 最后程序结束。此时登录数据库服务

1.MySQL 创建用户2.MySQL 的创建用户和授权mysql>mysql> create user user_test identified by '123456'; 或 create user user_test@'1.1.1.1' identified by '123456';Query OK, 0 rows affected (0.00 sec)mysql...

MySQL 模糊搜索 LIKE 是否区分大小写,取决于表的 COLLATE，默认是不区分大小写的，如果 COLLATE=utf8_bin 即二进制形式就是区分大小写的。在 ORM 中过滤的时候会写 xxx.objects.filter(name__contains=‘sxn’) 和 xxx.objects.filter(name__icontains=‘sxn’) 转成的 SQL分别是: LIKE BINARY 和 LIKE

悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在应用层中实现了加锁机制，也无法保证外部系统不会修改数据）。需要注意的是，在事务中，只有SELECT … FOR UPDATE 或LOCK IN SHARE MODE 相同数据时会等待其它事务结束后才执行，一般SELECT … 则不受此影响。拿上面的实例来说，当我执行select stat...

mysql数据库，当且仅当引擎是InnoDB，才支持事务。对于一个MYSQL数据库（InnoDB），事务的开启与提交模式无非下面这两种情况：1>若参数autocommit=0，事务则在用户本次对数据进行操作时自动开启，在用户执行commit命令时提交，用户本次对数据库开始进行操作到用户执行commit命令之间的一系列操作为一个完整的事务周期。若不执行commit命令，系统则默认事务回滚。...

对于 mysql 的 datetime 列，如果你 insert 的是 date（只有年月日），那么实际写入时会把时分秒设置为0 从而保存到数据库mysql> CREATE TABLE `zzz0210`-> (`id` bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'ID',-> `age` int(11) UN...