1.数据存储的方式不同，MyISAM 中的数据和索引是分开存储的，而 InnoDB 是把索引和数据存储在同一个文件里面。 2.对于事务的支持不同，MyISAM 不支持事务，而 InnoDB 支持 ACID 特性的事务处理 3.对于锁的支持不同，MyISAM 只支持表锁，而 InnoDB 可以根据不同的情况，支持行锁，表锁，间隙锁，临键锁 4.MyISAM 不支持外键，InnoDB 支持外键 当然也可以从索引结构、存储限制等方面，更加深入的回答。 具体参考如下官方文档：https://dev.mysql.com/doc/refman/8.0/en/innodb-introduction.htm ...

特点 InnoDB MyISAM Memory 存储限制 64TB 有 有 事务安全 支持 – – 锁机制 行锁 表锁 表锁 B+tree索引 支持 支持 支持 Hash索引 – – 支持 全文索引 支持(5.6版本之后) 支持 – 空间使用 高 低 n/a 内存使用 高 低 中等 批量插入速度 低 高 高 支持外键 支持 – – ...

Memory介绍 Memory引擎的表数据时存储在内存中的，由于受到硬件问题、或断电问题的影响，只能将这些表作为 临时表或缓存使用。 Memory特点 数据存储在内存中，读取速度非常快。 不支持事务和持久性，数据在数据库重启时丢失。 适合用作缓存或临时存储。 表级锁定 Memory文件 xxx.sdi：存储表结构信息创建表 my_memory , 指定Memory存储引擎 create table my_memory( id int, name varchar(10) ) engine = Memory ; ...

MyISAM介绍 MyISAM是MySQL早期的默认存储引擎。 MyISAM特点 不支持事务，不提供ACID特性。 支持表级锁定，性能较差于InnoDB在高并发环境中。 较快的读取性能，适用于只读或读写很少的应用。 没有外键约束。 MyISAM文件 xxx.sdi：存储表结构信息 xxx.MYD: 存储数据 xxx.MYI: 存储索引创建表 my_myisam , 并指定MyISAM存储引擎 create table my_myisam( id int, name varchar(10) ) engine = MyISAM ; ...

InnoDB介绍 InnoDB是一种兼顾高可靠性和高性能的通用存储引擎，在 MySQL 5.5 之后，InnoDB是默认的 MySQL 存储引擎。 InnoDB特点 支持事务，提供ACID（原子性、一致性、隔离性、持久性）特性。 支持行级锁定，适用于高并发环境。 支持外键约束，确保数据一致性。 具有自动崩溃恢复和日志文件，以确保数据的持久性。 InnoDB文件 xxx.ibd：xxx代表的是表名，innoDB引擎的每张表都会对应这样一个表空间文件，存储该表的表结 构（frm-早期的 、sdi-新版的）、数据和索引。参数：innodb_file_per_table show variables like 'innodb_file_per_table' 如果该参数开启，代表对于InnoDB引擎的表，每一张表都对应一个ibd文件。我们直接打开MySQL的 数据存放目录, 这个目录下有很多文件 夹，不同的文件夹代表不同的数据库. 注意:idb是二进制文件，不可以使用记事本直接打开，可以使用mysql提供指令打开 以从ibd文件中提取sdi信息，而sdi数据字典信息中就包含该表的表结构。 注意:使用cmd名称窗口查看 ibd2sdi tb_account.ibd ...

客户端应用程序：客户端应用程序是与MySQL数据库交互的用户或应用程序。这些应用程序使用MySQL客户端库来建立连接、发送SQL查询和接收查询结果。 SQL解释器：SQL解释器负责解析客户端应用程序发送的SQL查询语句，将其转换为内部数据结构，然后将其传递给查询优化器。 查询优化器：查询优化器是MySQL的核心组件之一。它分析SQL查询，确定最佳执行计划，并生成一组执行操作，以便从数据库中检索所需的数据。查询优化器考虑了表的索引、表之间的关系以及其他因素来提高查询性能。 存储引擎：MySQL支持多个存储引擎，每个存储引擎负责数据的物理存储和检索。常见的存储引擎包括： InnoDB：支持事务、行级锁定、外键和高并发性。 MyISAM：不支持事务，但具有快速读取性能。 Memory：将数据存储在内存中，用于快速读取和临时存储。 连接池：连接池是用于管理数据库连接的组件。它负责创建、维护和分配数据库连接，以降低连接建立和断开的开销，提高性能。 查询缓存：查询缓存用于存储已执行查询的结果集，以便在将来相同查询的情况下能够快速检索结果。不过，在高并发写入环境中，查询缓存可能会降低性能，因此有时会被禁用。 MySQL服务器：MySQL服务器是数据库管理系统的核心。它接收来自客户端应用程序的SQL查询，通过SQL解释器和查询优化器处理查询，然后将查询委托给适当的存储引擎执行。MySQL服务器还负责安全性、权限管理、事务控制、并发控制、崩溃恢复和日志记录等任务。 日志文件：MySQL使用多种日志文件来记录数据库活动，包括： 二进制日志（Binary Logs）：记录所有更改数据的SQL语句，用于复制和恢复。 错误日志（Error Log）：记录数据库错误和警告信息。 查询日志（Query Log）：记录所有SQL查询，通常用于调试目的。 数据文件和表空间：数据文件是用于存储表数据和索引的物理文件。这些文件通常被组织成表空间，不同的存储引擎可以在不同的表空间中存储数据。 表和索引：表是MySQL数据库中的主要数据存储单元，它们包含了数据行。索引用于加速数据检索操作，提高查询性能。 系统变量和参数文件：MySQL具有一组系统变量，允许管理员配置数据库的行为。这些变量的配置信息通常存储在参数文件中，以便进行高级配置。 ...

NTP，英文全称：Network Time Protocol，中文全名网络时间协议，是一种用于在计算机网络中同步设备时钟的协议。 它的主要目标是确保网络中的各个设备都具有一致的时间参考，以便它们可以协同工作，进行时间戳记录、数据同步和各种计算任务。 NTP采用分层结构来确保时间同步，使网络中的所有设备都能获得准确的时间信息。 ...

点击围观  ...

这是一个用于监控服务器磁盘利用率的shell脚本，它的功能和意义如下： 第一行是一个特殊的注释，用于指定执行这个脚本的解释器，这里是bash。 第三行到第十行是一些变量的定义，用于设置监控的参数，比如要监控哪些磁盘分区，报警的阈值是多少，检测的频率是多少，日志文件的位置和名称是什么等。 第十二行到第二十四行是一个函数的定义，叫做send_mail，它的作用是发送邮件给指定的收件人，告知他们哪些磁盘分区已经超过了阈值。这个函数需要一个参数，就是超过阈值的分区名称和利用率。 第二十六行到第四十八行是另一个函数的定义，叫做monitor_disk，它是主循环函数，它的作用是不断地检测磁盘利用率，并且如果发现有超过阈值的情况，就调用send_mail函数发送邮件，并且记录日志文件。这个函数没有参数，但是会使用前面定义的一些变量。 第五十行是调用monitor_disk函数的语句，这样就可以开始执行监控任务了。 #!/bin/bash # 监控服务器磁盘利用率的shell脚本 # 定义要监控的磁盘分区，可以有多个，用空格隔开 PARTITIONS="/dev/sda1 /dev/sdb1" # 定义报警阈值，单位为百分比 THRESHOLD=80 # 定义检测频率，单位为秒 INTERVAL=60 # 定义日志文件的路径和名称 LOGFILE=/tmp/disk_monitor.log # 定义邮件发送函数，需要安装mailx命令 send_mail(){ # 定义收件人邮箱地址，可以有多个，用空格隔开 MAILTO="user1@example.com user2@example.com" # 定义邮件主题 SUBJECT="Disk Usage Alert" # 定义邮件正文 MESSAGE="The following partitions have reached the threshold of $THRESHOLD%: $1" # 发送邮件 echo $MESSAGE | mailx -s "$SUBJECT" $MAILTO } # 定义主循环函数 monitor_disk(){ while true do # 获取当前时间 DATE=$(date "+%Y-%m-%d %H:%M:%S") # 遍历要监控的磁盘分区 for PARTITION in $PARTITIONS do # 获取磁盘利用率，去掉百分号 USAGE=$(df -h | grep $PARTITION | awk '{print $5}' | sed 's/%//') # 判断是否超过阈值 if [ $USAGE -ge $THRESHOLD ] then # 记录日志文件 echo "$DATE $PARTITION usage: $USAGE%" >> $LOGFILE # 调用邮件发送函数，传入超过阈值的分区名称和利用率 send_mail "$PARTITION usage: $USAGE%" fi done # 等待一定时间后再次检测 sleep $INTERVAL done } # 调用主循环函数 monitor_disk </div> ...

大家好，我是不念，这次，来说说 MySQL 的锁，主要是 Q&A 的形式，看起来会比较轻松。 在 MySQL 里，根据加锁的范围，可以分为全局锁、表级锁和行锁三类。 全局锁 全局锁是怎么用的？ 要使用全局锁，则要执行这条命令： flush tables with read lock 执行后，整个数据库就处于只读状态了，这时其他线程执行以下操作，都会被阻塞： 对数据的增删改操作，比如 insert、delete、update等语句； 对表结构的更改操作，比如 alter table、drop table 等语句。 如果要释放全局锁，则要执行这条命令： unlock tables 当然，当会话断开了，全局锁会被自动释放。 全局锁应用场景是什么？ 全局锁主要应用于做全库逻辑备份，这样在备份数据库期间，不会因为数据或表结构的更新，而出现备份文件的数据与预期的不一样。 举个例子大家就知道了。 在全库逻辑备份期间，假设不加全局锁的场景，看看会出现什么意外的情况。 如果在全库逻辑备份期间，有用户购买了一件商品，一般购买商品的业务逻辑是会涉及到多张数据库表的更新，比如在用户表更新该用户的余额，然后在商品表更新被购买的商品的库存。 那么，有可能出现这样的顺序： 先备份了用户表的数据； 然后有用户发起了购买商品的操作； 接着再备份商品表的数据。 也就是在备份用户表和商品表之间，有用户购买了商品。 这种情况下，备份的结果是用户表中该用户的余额并没有扣除，反而商品表中该商品的库存被减少了，如果后面用这个备份文件恢复数据库数据的话，用户钱没少，而库存少了，等于用户白嫖了一件商品。 所以，在全库逻辑备份期间，加上全局锁，就不会出现上面这种情况了。 加全局锁又会带来什么缺点呢？ 加上全局锁，意味着整个数据库都是只读状态。 那么如果数据库里有很多数据，备份就会花费很多的时间，关键是备份期间，业务只能读数据，而不能更新数据，这样会造成业务停滞。 既然备份数据库数据的时候，使用全局锁会影响业务，那有什么其他方式可以避免？ 有的，如果数据库的引擎支持的事务支持可重复读的隔离级别，那么在备份数据库之前先开启事务，会先创建 Read View，然后整个事务执行期间都在用这个 Read View，而且由于 MVCC 的支持，备份期间业务依然可以对数据进行更新操作。 因为在可重复读的隔离级别下，即使其他事务更新了表的数据，也不会影响备份数据库时的 Read View，这就是事务四大特性中的隔离性，这样备份期间备份的数据一直是在开启事务时的数据。 备份数据库的工具是 mysqldump，在使用 mysqldump 时加上 –single-transaction 参数的时候，就会在备份数据库之前先开启事务。这种方法只适用于支持「可重复读隔离级别的事务」的存储引擎。 InnoDB 存储引擎默认的事务隔离级别正是可重复读，因此可以采用这种方式来备份数据库。 但是，对于 MyISAM 这种不支持事务的引擎，在备份数据库时就要使用全局锁的方法。 表级锁 MySQL 表级锁有哪些？具体怎么用的。 MySQL 里面表级别的锁有这几种： 表锁； 元数据锁（MDL）; 意向锁； AUTO-INC 锁； 表锁 先来说说表锁。 如果我们想对学生表（t_student）加表锁，可以使用下面的命令： //表级别的共享锁，也就是读锁； lock tables t_student read; //表级别的独占锁，也就是写锁； lock tables t_stuent write; 需要注意的是，表锁除了会限制别的线程的读写外，也会限制本线程接下来的读写操作。 也就是说如果本线程对学生表加了「共享表锁」，那么本线程接下来如果要对学生表执行写操作的语句，是会被阻塞的，当然其他线程对学生表进行写操作时也会被阻塞，直到锁被释放。 要释放表锁，可以使用下面这条命令，会释放当前会话的所有表锁： unlock tables 另外，当会话退出后，也会释放所有表锁。 不过尽量避免在使用 InnoDB 引擎的表使用表锁，因为表锁的颗粒度太大，会影响并发性能，InnoDB 牛逼的地方在于实现了颗粒度更细的行级锁。 元数据锁 再来说说元数据锁（MDL）。 我们不需要显示的使用 MDL，因为当我们对数据库表进行操作时，会自动给这个表加上 MDL： 对一张表进行 CRUD 操作时，加的是 MDL 读锁； 对一张表做结构变更操作的时候，加的是 MDL 写锁； MDL 是为了保证当用户对表执行 CRUD 操作时，防止其他线程对这个表结构做了变更。 当有线程在执行 select 语句（ 加 MDL 读锁）的期间，如果有其他线程要更改该表的结构（ 申请 MDL 写锁），那么将会被阻塞，直到执行完 select 语句（ 释放 MDL 读锁）。 反之，当有线程对表结构进行变更（ 加 MDL 写锁）的期间，如果有其他线程执行了 CRUD 操作（ 申请 MDL 读锁），那么就会被阻塞，直到表结构变更完成（ 释放 MDL 写锁）。 MDL 不需要显示调用，那它是在什么时候释放的? MDL 是在事务提交后才会释放，这意味着事务执行期间，MDL 是一直持有的。 那如果数据库有一个长事务（所谓的长事务，就是开启了事务，但是一直还没提交），那在对表结构做变更操作的时候，可能会发生意想不到的事情，比如下面这个顺序的场景： 首先，线程 A 先启用了事务（但是一直不提交），然后执行一条 select 语句，此时就先对该表加上 MDL 读锁； 然后，线程 B 也执行了同样的 select 语句，此时并不会阻塞，因为「读读」并不冲突； 接着，线程 C 修改了表字段，此时由于线程 A 的事务并没有提交，也就是 MDL 读锁还在占用着，这时线程 C 就无法申请到 MDL 写锁，就会被阻塞， 那么在线程 C 阻塞后，后续有对该表的 select 语句，就都会被阻塞，如果此时有大量该表的 select 语句的请求到来，就会有大量的线程被阻塞住，这时数据库的线程很快就会爆满了。 为什么线程 C 因为申请不到 MDL 写锁，而导致后续的申请读锁的查询操作也会被阻塞？ 这是因为申请 MDL 锁的操作会形成一个队列，队列中写锁获取优先级高于读锁，一旦出现 MDL 写锁等待，会阻塞后续该表的所有 CRUD 操作。 所以为了能安全的对表结构进行变更，在对表结构变更前，先要看看数据库中的长事务，是否有事务已经对表加上了 MDL 读锁，如果可以考虑 kill 掉这个长事务，然后再做表结构的变更。 意向锁 接着，说说意向锁。 在使用 InnoDB 引擎的表里对某些记录加上「共享锁」之前，需要先在表级别加上一个「意向共享锁」； 在使用 InnoDB 引擎的表里对某些纪录加上「独占锁」之前，需要先在表级别加上一个「意向独占锁」； 也就是，当执行插入、更新、删除操作，需要先对表加上「意向独占锁」，然后对该记录加独占锁。 而普通的 select 是不会加行级锁的，普通的 select 语句是利用 MVCC 实现一致性读，是无锁的。 不过，select 也是可以对记录加共享锁和独占锁的，具体方式如下： //先在表上加上意向共享锁，然后对读取的记录加共享锁 select ... lock in share mode; //先表上加上意向独占锁，然后对读取的记录加独占锁 select ... for update; 意向共享锁和意向独占锁是表级锁，不会和行级的共享锁和独占锁发生冲突，而且意向锁之间也不会发生冲突，只会和共享表锁（lock tables … read）和独占表锁（lock tables … write）发生冲突。 表锁和行锁是满足读读共享、读写互斥、写写互斥的。 如果没有「意向锁」，那么加「独占表锁」时，就需要遍历表里所有记录，查看是否有记录存在独占锁，这样效率会很慢。 那么有了「意向锁」，由于在对记录加独占锁前，先会加上表级别的意向独占锁，那么在加「独占表锁」时，直接查该表是否有意向独占锁，如果有就意味着表里已经有记录被加了独占锁，这样就不用去遍历表里的记录。 所以，意向锁的目的是为了快速判断表里是否有记录被加锁。 AUTO-INC 锁 表里的主键通常都会设置成自增的，这是通过对主键字段声明 AUTO_INCREMENT 属性实现的。 之后可以在插入数据时，可以不指定主键的值，数据库会自动给主键赋值递增的值，这主要是通过 AUTO-INC 锁实现的。 AUTO-INC 锁是特殊的表锁机制，锁不是再一个事务提交后才释放，而是再执行完插入语句后就会立即释放。 在插入数据时，会加一个表级别的 AUTO-INC 锁，然后为被 AUTO_INCREMENT 修饰的字段赋值递增的值，等插入语句执行完成后，才会把 AUTO-INC 锁释放掉。 那么，一个事务在持有 AUTO-INC 锁的过程中，其他事务的如果要向该表插入语句都会被阻塞，从而保证插入数据时，被 AUTO_INCREMENT 修饰的字段的值是连续递增的。 但是， AUTO-INC 锁再对大量数据进行插入的时候，会影响插入性能，因为另一个事务中的插入会被阻塞。 因此， 在 MySQL 5.1.22 版本开始，InnoDB 存储引擎提供了一种轻量级的锁来实现自增。 一样也是在插入数据的时候，会为被 AUTO_INCREMENT 修饰的字段加上轻量级锁，然后给该字段赋值一个自增的值，就把这个轻量级锁释放了，而不需要等待整个插入语句执行完后才释放锁。 InnoDB 存储引擎提供了个 innodb_autoinc_lock_mode 的系统变量，是用来控制选择用 AUTO-INC 锁，还是轻量级的锁。 当 innodb_autoinc_lock_mode = 0，就采用 AUTO-INC 锁，语句执行结束后才释放锁； 当 innodb_autoinc_lock_mode = 2，就采用轻量级锁，申请自增主键后就释放锁，并不需要等语句执行后才释放。 当 innodb_autoinc_lock_mode = 1： 普通 insert 语句，自增锁在申请之后就马上释放； 类似 insert … select 这样的批量插入数据的语句，自增锁还是要等语句结束后才被释放； 当 innodb_autoinc_lock_mode = 2 是性能最高的方式，但是当搭配 binlog 的日志格式是 statement 一起使用的时候，在「主从复制的场景」中会发生数据不一致的问题。 举个例子，考虑下面场景： session A 往表 t 中插入了 4 行数据，然后创建了一个相同结构的表 t2，然后两个 session 同时执行向表 t2 中插入数据。 如果 innodb_autoinc_lock_mode = 2，意味着「申请自增主键后就释放锁，不必等插入语句执行完」。那么就可能出现这样的情况： session B 先插入了两个记录，(1,1,1)、(2,2,2)； 然后，session A 来申请自增 id 得到 id=3，插入了（3,5,5)； 之后，session B 继续执行，插入两条记录 (4,3,3)、 (5,4,4)。 可以看到，session B 的 insert 语句，生成的 id 不连续。 当「主库」发生了这种情况，binlog 面对 t2 表的更新只会记录这两个 session 的 insert 语句，如果 binlog_format=statement，记录的语句就是原始语句。记录的顺序要么先记 session A 的 insert 语句，要么先记 session B 的 insert 语句。 但不论是哪一种，这个 binlog 拿去「从库」执行，这时从库是按「顺序」执行语句的，只有当执行完一条 SQL 语句后，才会执行下一条 SQL。因此，在从库上「不会」发生像主库那样两个 session 「同时」执行向表 t2 中插入数据的场景。所以，在备库上执行了 session B 的 insert 语句，生成的结果里面，id 都是连续的。这时，主从库就发生了数据不一致。 要解决这问题，binlog 日志格式要设置为 row，这样在 binlog 里面记录的是主库分配的自增值，到备库执行的时候，主库的自增值是什么，从库的自增值就是什么。 所以，当 innodb_autoinc_lock_mode = 2 时，并且 binlog_format = row，既能提升并发性，又不会出现数据一致性问题。 行级锁 InnoDB 引擎是支持行级锁的，而 MyISAM 引擎并不支持行级锁。 前面也提到，普通的 select 语句是不会对记录加锁的，因为它属于快照读。如果要在查询时对记录加行锁，可以使用下面这两个方式，这种查询会加锁的语句称为锁定读。 //对读取的记录加共享锁 select ... lock in share mode; //对读取的记录加独占锁 select ... for update; 上面这两条语句必须在一个事务中，因为当事务提交了，锁就会被释放，所以在使用这两条语句的时候，要加上 begin、start transaction 或者 set autocommit = 0。 共享锁（S锁）满足读读共享，读写互斥。独占锁（X锁）满足写写互斥、读写互斥。 行级锁的类型主要有三类： Record Lock，记录锁，也就是仅仅把一条记录锁上； Gap Lock，间隙锁，锁定一个范围，但是不包含记录本身； Next-Key Lock：Record Lock + Gap Lock 的组合，锁定一个范围，并且锁定记录本身。 Record Lock Record Lock 称为记录锁，锁住的是一条记录。而且记录锁是有 S 锁和 X 锁之分的： 当一个事务对一条记录加了 S 型记录锁后，其他事务也可以继续对该记录加 S 型记录锁（S 型与 S 锁兼容），但是不可以对该记录加 X 型记录锁（S 型与 X 锁不兼容）; 当一个事务对一条记录加了 X 型记录锁后，其他事务既不可以对该记录加 S 型记录锁（S 型与 X 锁不兼容），也不可以对该记录加 X 型记录锁（X 型与 X 锁不兼容）。 举个例子，当一个事务执行了下面这条语句： mysql > begin; mysql > select * from t_test where id = 1 for update; 就是对 t_test 表中主键 id 为 1 的这条记录加上 X 型的记录锁，这样其他事务就无法对这条记录进行修改了。 当事务执行 commit 后，事务过程中生成的锁都会被释放。 Gap Lock Gap Lock 称为间隙锁，只存在于可重复读隔离级别，目的是为了解决可重复读隔离级别下幻读的现象。 假设，表中有一个范围 id 为（3，5）间隙锁，那么其他事务就无法插入 id = 4 这条记录了，这样就有效的防止幻读现象的发生。 间隙锁虽然存在 X 型间隙锁和 S 型间隙锁，但是并没有什么区别，间隙锁之间是兼容的，即两个事务可以同时持有包含共同间隙范围的间隙锁，并不存在互斥关系，因为间隙锁的目的是防止插入幻影记录而提出的。 Next-Key Lock Next-Key Lock 称为临键锁，是 Record Lock + Gap Lock 的组合，锁定一个范围，并且锁定记录本身。 假设，表中有一个范围 id 为（3，5] 的 next-key lock，那么其他事务即不能插入 id = 4 记录，也不能修改 id = 5 这条记录。 所以，next-key lock 即能保护该记录，又能阻止其他事务将新纪录插入到被保护记录前面的间隙中。 next-key lock 是包含间隙锁+记录锁的，如果一个事务获取了 X 型的 next-key lock，那么另外一个事务在获取相同范围的 X 型的 next-key lock 时，是会被阻塞的。 比如，一个事务持有了范围为 (1, 10] 的 X 型的 next-key lock，那么另外一个事务在获取相同范围的 X 型的 next-key lock 时，就会被阻塞。 虽然相同范围的间隙锁是多个事务相互兼容的，但对于记录锁，我们是要考虑 X 型与 S 型关系，X 型的记录锁与 X 型的记录锁是冲突的。 插入意向锁 一个事务在插入一条记录的时候，需要判断插入位置是否已被其他事务加了间隙锁（next-key lock 也包含间隙锁）。 如果有的话，插入操作就会发生阻塞，直到拥有间隙锁的那个事务提交为止（释放间隙锁的时刻），在此期间会生成一个插入意向锁，表明有事务想在某个区间插入新记录，但是现在处于等待状态。 举个例子，假设事务 A 已经对表加了一个范围 id 为（3，5）间隙锁。 当事务 A 还没提交的时候，事务 B 向该表插入一条 id = 4 的新记录，这时会判断到插入的位置已经被事务 A 加了间隙锁，于是事物 B 会生成一个插入意向锁，然后将锁的状态设置为等待状态（PS：MySQL 加锁时，是先生成锁结构，然后设置锁的状态，如果锁状态是等待状态，并不是意味着事务成功获取到了锁，只有当锁状态为正常状态时，才代表事务成功获取到了锁），此时事务 B 就会发生阻塞，直到事务 A 提交了事务。 插入意向锁名字虽然有意向锁，但是它并不是意向锁，它是一种特殊的间隙锁，属于行级别锁。 如果说间隙锁锁住的是一个区间，那么「插入意向锁」锁住的就是一个点。因而从这个角度来说，插入意向锁确实是一种特殊的间隙锁。 插入意向锁与间隙锁的另一个非常重要的差别是：尽管「插入意向锁」也属于间隙锁，但两个事务却不能在同一时间内，一个拥有间隙锁，另一个拥有该间隙区间内的插入意向锁（当然，插入意向锁如果不在间隙锁区间内则是可以的）。 ...

Checkmk是一款开源的网络监控工具，以其灵活性和可扩展性而闻名。 它允许管理员监测网络性能、服务器状态和应用程序运行情况。 官网：https://checkmk.com/l/c/top-network-monitoring 主要功能和特点 基于代理程序的监控：Checkmk使用代理程序来监测网络设备，提供了高度详细的信息。 多种插件：Checkmk支持多种插件，可用于监测各种不同的设备和应用程序。 可定制性：管理员可以根据自己的需求配置监控规则和仪表板。 强大的性能数据：Checkmk提供了大量的性能数据，有助于分析和优化网络性能。 优点 开源：Checkmk是开源工具，允许用户自由定制和扩展。 灵活性：它适用于各种复杂的监控场景，可以满足不同需求。 大型社区支持：Checkmk有庞大的用户社区，可以获取帮助和支持。 缺点 学习曲线：对于初学者来说，学习和配置可能需要一些时间。 需要自行维护：作为开源工具，需要自行维护和升级。 ...

网络数据包代理（NPB）是一种主动设备，它设计用于接收、处理和分发网络流量，以实现更高级的网络可视性和优化。 NPB通常包括多个输入端口和输出端口，允许管理员配置规则，以根据特定的标准选择性地将数据包从输入端口传递到输出端口。 NPB特点 高级流量处理：NPB可以根据预定义的规则和策略对流量进行处理，例如过滤、负载均衡、数据包修复、流量切片等。 智能流量分发：NPB具有智能流量分发功能，根据特定的规则将数据包引导到适当的监视或安全工具，以确保工具的高效利用。 多源流量处理：NPB能够同时处理来自多个网络源的流量，例如网络链路、交换机、路由器或TAP。这使得它们在大型网络中特别有用。 灵活性和可扩展性：NPB通常提供了更大的灵活性，管理员可以根据需要配置规则和策略，以适应不同的监控和分析要求。此外，它们可以在多个监视工具之间均匀分发流量，以防止工具过载，从而确保最佳的工具性能。 NPB类型 固定网络数据包代理： 适用情况：固定网络数据包代理通常适用于具有明确定义网络拓扑的情况，其中网络结构相对简单且不经常更改。这种类型的NBP适合于聚合外部无源分路器、SPAN（Switched Port Analyzer）端口以及安全/监控设备。 特点：它通常是较小的设备，专门用于特定任务，例如连接到特定交换机端口的监控设备。这些设备通常不支持模块化设计，而是为特定用途而构建。 模块化网络数据包代理： 适用情况：模块化网络数据包代理是一种多用途平台，适用于各种网络拓扑和可见性场景。它们可以适应不同的需求，包括旁路、被动和代理功能。 特点：这些NBP通常具有可配置的模块化设计，允许用户根据其特定需求进行自定义配置。它们通常支持多种功能，包括流量聚合、过滤、镜像和负载平衡。这种灵活性使其适用于不同的网络环境。 混合数据包代理/旁路： 适用情况：混合数据包代理/旁路设备是一种组合式一体化设备，它融合了旁路交换机和数据包代理的功能和优点。它可以用于各种网络部署，为不同的网段提供广泛的数据包过滤、分发、聚合和镜像功能。 特点：这些设备结合了旁路交换机的特性，例如高可用性和快速故障转移，以及数据包代理的功能，如流量过滤和负载平衡。这使其成为一个多功能工具，可满足各种网络监控需求。 NPB应用领域 网络性能优化：NPB可以帮助优化网络性能，通过负载均衡、流量切片和过滤，确保监控工具获得最相关的数据，提高性能分析的效率。 安全监控：NPB在安全监控中发挥重要作用，通过检测异常活动、入侵检测和威胁分析来提高网络安全性。 数据包修复：NPB能够修复损坏的数据包，以确保分析工具不会因数据包损坏而受到干扰。 合规性：NPB可以满足合规性监控的需求，通过提供高级流量控制和数据包分析来满足合规性要求。 尽管NPB在网络监控和优化中提供了许多高级功能，但它们也需要更多的配置和管理。 管理员需要定义规则和策略，以确保NPB按预期工作。 此外，NPB通常是较昂贵的解决方案，适用于对高级流量管理和处理有需求的组织。 ...

流量接入点（TAP）是一种被动设备，用于监控和捕获网络流量，而不干扰网络的正常运行，部署在网络基础设施内的战略位置，以拦截和复制网络数据包。 它的主要工作是将通过特定链路或网段传输的数据包复制到监视设备，如网络分析仪、数据包捕获工具或安全设备。 1.1 TAP特点 非侵入性：TAP以非侵入性的方式工作，不会中断网络流量的传输，也不会引入延迟。 数据包完整性：TAP提供对网络通信的完整可见性，捕获所有流经链路或网段的数据包，包括入站和出站流量。 网络监控：TAP可用于链路监控、网络性能监测、故障排除以及安全事件检测。 数据复制：TAP复制原始数据包，将其传递给连接的监视设备，以便进行进一步的分析和处理。 1.2 TAP类型 TAP可以分为有源网络TAP和无源网络TAP，这两种类型的TAP在网络流量监控中有不同的应用和特点。 有源网络TAP： 特点：有源网络TAP是一种主动设备，它接收来自网络链路的数据流，然后复制并转发这些数据流到监控或分析设备。它在数据流经过时会放大信号，以确保数据的完整性和可见性。 应用：有源网络TAP适用于大型或复杂网络中，需要扩展信号以维持数据完整性的情况。它们通常用于支持高速链路、远距离传输或需要信号放大的环境。 无源网络TAP： 特点：无源网络TAP是一种被动设备，它不引入延迟、不放大信号，而只复制数据包。它的工作方式类似于网络的“看客”，不对数据流做任何干预。 应用：无源网络TAP适用于大多数网络监控场景，特别是当需要非侵入性监控网络链路或网段时。它们通常部署在网络拓扑中的战略点，以捕获和复制流经的数据包，而不影响原始流量。 1.3 TAP的应用领域 网络性能监控：通过捕获网络流量，TAP有助于检测网络性能问题，例如带宽利用率、延迟、数据包丢失等。 安全监控：TAP可用于监视网络中的异常活动、潜在的安全威胁和攻击，以及入侵检测系统（IDS）和入侵预防系统（IPS）的操作。 合规性：许多组织需要满足合规性要求，TAP提供了对网络通信的全面可见性，以满足合规性监控的需求。 数据包捕获：网络管理员和安全专业人员可以使用TAP来捕获网络数据包以进行离线分析，以便进行深入调查和故障排除。 然而，尽管TAP在网络监控中发挥着重要作用，但它也存在一些局限性。 TAP不能对流量进行处理或过滤，而只是复制原始数据包。 此外，需要在网络中的多个位置部署TAP才能全面覆盖网络。 ...

Garuda Linux，作为一款 用户友好且基于 Arch Linux 的发行版，由于其可高度定制和可扩展性，近期已经吸引了大批用户。 Garuda Linux 提供了众多选项以满足不同的使用场景，无论是编程还是游戏。 目前，Garuda Linux 的最新发布版，Garuda Linux “Spizaetus”现已可用。 下面，让我来引导你了解一下这个版本。 ? Garuda Linux “Spizaetus”：有哪些新变化？ 这个版本的代号“Spizaetus” 是来源于一种通常在美洲热带地区发现的鹰鹞。此次发布的主要亮点包括： 提供 Hyprland ISO Ugrep 取代了 Grep 提供了实验性的 KDE Plasma 6 仓库 提供 Hyprland ISO 在这个 Garuda Linux 的版本中，推出了带有 Hyprland动态平铺 Wayland 组合器的新 ISO，这让流畅的动画和轻松的窗口平铺成为可能。 在此，开发者之一的 dr460nf1r3表示： 关注精美的界面和模糊的窗口，Hyprland 无疑是 Garuda 的完美搭配。 ? 然而，不幸的是，他们不得不停止一些其它变体的更新，因为这些变体并未得到妥善维护。受影响的变体包括：MATE、LXQt-Kwin、KDE-git和Wayfire。 Ugrep 取代了 Grep grep命令行工具已被性能更强的ugrep文件模式搜索器所取代，后者声称自己是“超快速且用户友好的 Grep 替代品”。 这是一个令人感兴趣的改变，我们期待看到用户的反馈。 实验性的 KDE Plasma 6 仓库（请谨慎！） 开发者们还引入了一个名为 chaotic-aur-kde的实验性仓库，以提供早期版本的 Plasma 6。 请注意，这是为那些想提前体验 Plasma 6 设计的用户而设，并不建议将其用于生产环境。 一位开发者补充道： 我们一直在努力通过特定的 chaotic-aur-kde 仓库，提供 Plasma 6 的早期构建。 这可以让我们初步探索未来的 Plasma 6 将会是什么样子 – 它的首个版本计划在 2024 年 2 月发布。无需多说，这些都是来自主分支的实验性构建版，因此只适合喜欢接受挑战认的人去体验。 ?️ 其它的变化和改进 除了上述的亮点之外，还有些其他值得一提的细化调整： garuda-update 工具已更新用于处理近期由于包名称变更引发的冲突。 Plymouth已被移除，现在在启动时，会显示终端的输出内容。 对他们的基础设施进行了各种更新，以服务用户。 为 Garuda Linux 安装了一个专用的 Lemmy 实例。 你可以查阅 官方公告来获取更多详细信息。 ...

Skiff Mail 是一款开源的端到端加密电子邮件服务，非常注重隐私。在各方面，包括用户体验方面，它都是 Gmail 和 Proton mail 的不错替代品。 虽然与竞争对手相比，它相当新，但它的一些注重隐私的功能可能会给你留下深刻的印象。 此外，还推出了一项新的快速别名功能。我试用了一下，感觉非常方便。 快速别名：一次性无忧设置 一般来说，你可以使用一些 电子邮件保护工具（例如 SimpleLogin）或从你的电子邮件提供商（无论是谁）创建电子邮件别名。 你可以选择记住电子邮件别名以供使用，或者在每次注册服务、新闻通讯或向你不认识的人提供联系信息时生成唯一的别名。 换句话说，大多数情况下，需要你进行多次交互才能使用多个电子邮件别名。 在这里，Skiff Mail允许你为自己声明一个完整的唯一子域，例如gojo.maskmy.id（正如我在测试用例中所做的那样）： 接下来，你所要做的就是 – 在激活它时将其视为你的网站地址，并在其之前添加任何内容作为电子邮件地址，例如 xyz@gojo.maskmy.id或demo@gojo.maskmy.id。 如上面的截图所示，你也可以选择生成一个随机名称来声明。 你可以从“设置Settings”菜单访问“快速别名Quick Aliases”功能： 因此，你不再需要生成电子邮件别名，但仍然可以通过这种方式拥有无限的别名。使其成为一次性设置解决方案，可供在线和离线使用。 我认为这些类型的别名应该有几个好处： 它使你无需访问该工具即可轻松创建新别名 使电子邮件别名看起来比垃圾邮件更真实 根据你的订阅，每人最多可以申请 3 个域名（Essential：1、Pro：2、Business：3）。并且，使用它们创建无限的电子邮件别名。 ...

兔兔不是凸凸,活在自己的热爱里而不是别人的眼光里  7p ...

_酷野,微胖黑色腰丝  5p ...

点击围观  ...

敏珍,没错就是发给你看的黑丝御姐  5p ...

主从延迟情况 我们先看看，哪些情况会导致主从延时： 从库机器性能：从库机器比主库的机器性能差，只需选择主从库一样规格的机器就好。 从库压力大：可以搞了一主多从的架构，还可以把 binlog 接入到 Hadoop 这类系统，让它们提供查询的能力。 从库过多：要避免复制的从节点数量过多，从库数据一般以3-5个为宜。 大事务：如果一个事务执行就要 10 分钟，那么主库执行完后，给到从库执行，最后这个事务可能就会导致从库延迟 10 分钟啦。日常开发中，不要一次性 delete 太多 SQL，需要分批进行，另外大表的 DDL 语句，也会导致大事务。 网络延迟：优化网络，比如带宽 20M 升级到 100M。 MySQL 版本低：低版本的 MySQL 只支持单线程复制，如果主库并发高，来不及传送到从库，就会导致延迟，可以换用更高版本的 MySQL，支持多线程复制。 主从延时解决方案 面试时，有些同学能回答出使用缓存、查询主库、提升机器配置等，仅仅这些么？ 最容易想到的方法，缩短主从同步时间： 提升从库机器配置，可以和主库一样，甚至更好； 避免大事务； 搞多个从库，即一主多从，分担从库查询压力； 优化网络宽带； 选择高版本 MySQL，支持主库 binlog 多线程复制。 也可以从业务场景考虑： 使用缓存：我们在同步写数据库的同时，也把数据写到缓存，查询数据时，会先查询缓存，不过这种情况会带来 MySQL 和 Redis 数据一致性问题。 查询主库：直接查询主库，这种情况会给主库太大压力，核心场景可以使用，比如订单支付。 如果能把上面基本回答出来，就已经非常厉害了，还有么？ 其实还可以在 MySQL 架构上来考虑。 主库对数据安全性较高，设置配置如下： sync_binlog = 1 innodb_flush_log_at_trx_commit = 1 而 slave 不需要这么高的数据安全，完全可以将 sync_binlog 设置为 0，或者关闭 binlog，innodb_flushlog 也可以设置为 0，来提高 sql 的执行效率。 架构方案：使用多台 slave 来分摊读请求，再从这些 slave 中取一台专用的服务器，只作为备份用，不进行其他任何操作，比如设置 sync_binlog 为0，或者关闭 binglog 等，提升从库查询性能。 ...