九师兄

这些配置项一般都会在 MyBatis 的数据源配置中出现，例如在 XML 配置文件中的 部分。确保这些配置项按照你的需求正确地设置，以确保 MyBatis 能够有效地管理数据库连接。在 MyBatis 中，你通常会配置一个数据源（DataSource）来管理数据库连接。: 连接在池中最小空闲时间，超过这个时间的连接将被逐出。: 在从池中获取连接时是否要进行验证（测试）。: 在每次驱逐连接时，要进行的最大测试次数。: 在归还连接到池时是否要进行验证（测试）。: 在连接空闲时是否要进行验证（测试）。

假设我们本地有个数据库，然后里面有很多表，我们要把数据导入到远程服务器该怎么做呢？MySQL WorkerBranch 是自带这个功能的。经过测试发现，经常遇到问题，可能无法正常传输。然后下一步、下一步，这里创建目标的schema。然后我们选择哪些数据库和表是要同步过去的。然后最后会生成给我们一个报告。第一步选择source。然后会获取元数据信息。然后创建schema。

本章是MySQL 8官方翻译。缓冲池处于计算机系统主存中的某个区域，用于InnoDB访问时缓存表以及索引数据。缓冲池允许直接从内存访问常用数据，从而加快处理速度。在专用服务器上，通常多达80%的物理内存分配给缓冲池。为了提高大量的读取操作，缓冲池被划分成可能包含多行的页。为了有效管理这些页的数据，缓冲池被实现为以页为元素的链表。通过一种 变体的LRU算法 (Least Recently Used Algorithm, 最近最少使用算法）使最近最少使用的数据 老化(即清除不常用的缓存)。

为什么要有分布式事务？因为在微服务大规模运用下，我们往往一个操作需要多个微服务来完成，这就涉及分布式事务了。Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA和XA事务模式，为用户打造一站式的分布式解决方案。在seata下我们看看都有哪些角色，以及角色都有什么作用?seata下主要有3个角色，下面来分别介绍。

在MySQL workbench中我们可以图示化的展示执行计划，输入SQL点击搜索+闪电的符号，就能图示化展示执行计划，蓝色代表执行的速度非常快，红色代表执行的速度较慢。下面是一个红色的案例，这个是全表扫描这个是非常有用的,MySQL explain不是很熟悉，可视化的话对小白就很有好的。

本章节主要是利用一致性Hash解决MySQL分库扩容难题，主要从以下几个方面来讲解。传统Hash分库会遇到什么问题一致性Hash的实现逻辑解决一致性Hash存储不均衡问题实例讲解扩容迁移过程一致性Hash面对的新挑战。

为什么MySQL执行计划使用了索引，SQL执行仍然很慢？首先我们要盖棺定论：MySQL用到了索引和执行时间没有必然关系，确定查询执行效率的是“扫描行数”与"回表次数“。并不是说我们用到了索引，查询速度就一定快，这本质上是没有关系的。主要是“扫描行数”与"回表次数“这两个决定的。

我们都知道在MySQL中，innodb是默认要加主键索引的，加了主键索引后会默认生成一个主键的索引树，然后其他的索引也是树，但是却不是聚集索引，只是节点指向的是主键索引的id。下面来看一个案例，我们有一个表，然后有一些字段，并且添加了是三个索引，表中的数据有50万的数据。type：索引检索类型，const代表常数（只找到唯一的记录） 查询，这个效率很高。rows：本次查询所扫描的行数，注意：这个值可能和最终结果不一致，扫描行数越少越好。select_type：查询类型，SIMPLE代表直接对表的简单查询。

下面看一个场景，这是用户访问记录表，在前端是按照时间升序排列，表中有50万的数据针对这样的查询我们以前都喜欢使用limit关键字查询，但是如果现在我想看5万页的数据会出现什么现象呢？可以看到数据耗时76秒之多，并且就算是创建了索引也是不行的，默认走了全表扫描的。我们来简单看看这个索引的分布情况，作为这个表的索引有2个一个是id，这是innodb默认的索引，这个是按照ID的升序排列的。另外一个索引是create_time,这个是按照时间进行升序排列的，不过这个不关联真实的数据，关联的是ID的指针。

以前我们模糊查询数据一般采用如下代码。针对上述情况，我们如果使用过ElasticSearch，那么可能会使用ES，但是要看具体的业务是不是真的需要，以及架构。增加es会带来几个问题，比如MySQL给出了折中的办法，从 MySQL 5.7.6 开始，MySQL内置了ngram全文解析器，允许对短文本进行全文检索查询，以替代like 关键字，对于复杂业务场景的全文检索查询，还是要用ES。

在阿里开发规范中有这样的一条强制规范【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。说明：索引文件具有 B-Tree 的最左前级匹配特性，如果左边的值末确定，那么无法使用此素引。这个解释不够详细，这里进行详细的说明。这里根据一个表进行说明。这里有个表，表中除了主键其他的字段都加了索引。这个表看起来没有什么问题，但是如果进行模糊查询那么就会有问题。看下面的情况。这里看到如果我们查询“133%”这里看着是命中了索引，这里为什么能命中索引呢？

MySQL的页大小（Page size）通常是16KB，这是因为在设计MySQL存储引擎时考虑了一些因素，包括性能、内存管理和存储空间利用率等。选择16KB作为页大小是在权衡以上因素后的一个妥协。然而，需要注意的是，页大小在不同的数据库管理系统（DBMS）和存储引擎中可能会有所不同，因此在特定的情况下，选择适合的页大小可能会对性能产生积极的影响。

MySQL 提供的 XAConnection 是用于实现分布式事务中的两阶段提交（Two-Phase Commit）协议。XA 是 X/Open (现在是 The Open Group) 提出的一个分布式事务协议标准，用于确保多个资源管理器（如数据库）在分布式环境中的事务处理的一致性和可靠性。在 XA 事务中，涉及到多个数据库或其他资源管理器的操作需要协调参与者（资源管理器）之间的一致性。

在SQL语句的分页查询中，limit 500000,10和limit 10速度一样快吗？在SQL语句的分页查询中，LIMIT 500000, 10 和 LIMIT 10 在速度上可能会有一些差异。当数据库引擎执行 LIMIT 500000, 10 时，它会首先跳过前面的500,000行数据，然后返回接下来的10行数据。相比之下，LIMIT 10 仅返回前10行数据，而不需要跳过任何数据，因此查询的速度可能更快。但是和两个元素有关数据量如果数据量很小的情况下，两者的差异很小。

要根据实际的查询需求和业务场景，考虑选择最常用的查询条件，将其作为索引的最左前缀列，以提高查询性能和索引的效用。所以如果只是单纯的使用b=2这个条件来查询，是没有办法用到索引的，因此在联合索引中只有先确认了前一个值，才能确定下一个值，如果有范围查询的话，联合家引中使用范围查询的字段后的家引任该条SQL中都不会起作用。当表中定义了一个由多列组成的复合索引，例如（col1, col2, col3），在查询时只能使用索引的最左前缀列或者最左前缀列的组合进行查询，才能充分利用索引的优势。

在介绍MVCC并发控制的原理之前，我们先普及两个知识点。要解决并发问题只有一种方案就是加锁。当然，锁不可避免的会导致性能下降，但是，锁也有乐观和悲观之分，上一讲我们聊到的，隔离级别中的串行化就是一种悲观的思想，可以直接避免并发事务中所有的问题，但是性能也是下降的非常严重。而MysQL 是如何在性能和一致性中权衡的呢？我们接着往下看。

以前看MySQL脏读、幻读以及不可重复读，总是很官方的语言来解释，或者案例搞得不是很好，很难记忆以及理解。本章比较通俗。我们以银行转账为例，在银行转账中，转账发起方要扣减金额，如果执行到最后一步的时候如果断电了，那么就会导致很严重的问题。比如转账发起方扣钱了，但是接收方没有收到钱，钱就无缘无故的减少了。如果要解决这个问题，那么就要保证两边的操作，必须是一个完整的整体，要么全部成功，要么全部失败。而数据库的事务就能达到这个效果。事务可以在出错的时候，可以进行回滚数据，达到像是没有修改的状态。

本章节我们主要来聊聊 MySQL索引为何使用B+树结构，而不是二叉树、红黑树、B树？MysQL的索引机制中，有一点可谓是路人皆知，既默认使用B+树作为底层的数据结构。有人会说树结构是以二分法查找数据，所以会在很大程度上提升检索性能，这点确实没错，但树结构有那么多，但为什么要选择B+树呢？而不选择二叉树、红黑树或B树呢？下面一起聊一聊这个话题。

索引的维护需要消耗额外的资源，并且对表的插入、更新和删除操作有一定的影响。如果表经常被频繁地执行这些写操作，而相对较少进行查询操作，那么过多的索引可能会导致性能下降，因此可以考虑减少索引的数量或选择性地创建索引。：如果某个表只会进行一次性的查询操作，而且查询的范围广泛，那么创建索引的收益可能很小。：你要建立的索引字段，但是查询的时候对该字段进行函数转换查询，这个相当于没有用到索引。我们经常说数据库的表，建立索引能增加查询速度，那么什么情况下，不需要建立索引呢？，那么创建索引对查询性能的提升可能不明显。

遇到一个问题，java 操作mysql ,然后调用过程是 java 到 nginx 然后到 mysql ，现在遇到异常我们部署的情况如下docker容器有2个，分别是flink_node容器 mysql_node容器。然后mysql_node容器内装机了mysql，并且暴露端口3306，但是这个端口是被nginx代理了，也是暴露出3306端口，我们再flink_node容器下访问的时候，绝大部分正常，但是偶然不正常报错信息如下我们的java伪代码如下。

今天有个需求是查询要支持特殊字符查询等，其实我们的产品写入数据的时候，限制了不能填写特殊字符，容纳后查询的时候还要支持特殊字符。

【代码】【MySQL】mysql status 详细解释。

4.如果你无法升级你的MySQL客户端，你可以尝试将你的MySQL用户的身份验证插件更改为旧版的mysql_native_password。这个错误通常发生在MySQL 8.0版本及以上，因为在这些版本中，MySQL引入了新的默认身份验证插件caching_sha2_password，以提供更安全的密码存储和验证方式。6.你可以创建一个新的MySQL用户，使用旧版本的mysql_native_password作为身份验证插件。

我们在主从架构下，我们如果所有的读取和写入如果都走主节点，那么主节点的压力就很大，如果能读写分离，那么就能大大的减缓主节点的压力。而ShardingJDBC恰巧能解决这个问题。Apache Sharding Sphere 是一款开源分布式数据库生态项目，旨在碎片化的异构数据库上层构建生态，在最大限度的复用数据库原生存算能力的前提下，进一步提供面向全局的扩展和叠加计算能力。其核心采用可插拔架构，对上以数据库协议及 SQL 方式提供诸多增强功能，包括数据分片、访问路由、数据安全等。

MySQL的explan是查看mysql 的执行计划的，这个能显示我们执行计划的优劣，可以根据这个优化SQL.MySQL执行计划中的Extra列提供了关于查询计划中额外信息的详细说明。绿色是好 红色是差。

如果对表的结构进行了更改，如添加、删除或修改了索引列，MySQL可能需要重新分析和优化查询计划，这可能会导致一段时间内索引失效。例如，如果有一个索引在列name上，但查询使用了 WHERE LOWER(name) = ‘john’，这个索引可能无法使用。当查询不包含索引列，或者使用了索引列的表达式，但该表达式导致了索引无法使用时，索引会失效。当查询中包含OR条件时，如果其中一个条件无法使用索引，整个查询可能会导致索引失效。在某些情况下，如果您使用了表达式索引，而查询中没有使用相同的表达式，索引也会失效。

MySQL的事务满足ACID的特性，所以MySQL得事务就是innodb是如何ACID这样一个特性的。

PostgresQL vs. MysQL 是在选择开源关系型数据库管理系统时的重要决策。PostgresQL 和 MysQL 都是经过时问验证的解决方案，可以与企业级解决方案（如 Oracle 和 SQL Server)竞争。MySQL 因其易用性和速度而闻名，而PostgreSQL 则拥有更多高级功能，这也是 PostgreSQL 经常被描述为开源版 Oracle 的原因。

Performance Schema提供了有关MySQL服务器内部运行的操作上的底层指标。为了解释清楚Performance Schema的工作机制，先介绍两个概念。第一个概念是程序插桩 (instrument）。程序插桩在MySQL代码中插入探测代码，以获取我们想了解的信息。例如，如果想收集关于元数据锁的使用情况，需要启用wait/lock/ meta-data/sql/mdl这个插桩。第二个概念是消费者表 (consumer），指的是存储关于程序插桩代码信息的表。

本章节主要是巧用MRR与BKA优化SQL与多关联表来提高查询速度。我们先来看看这个问题。主键索引是一棵 B+ 树，在这棵树上，每次只能根据一个主键 id 查到一行数据。因此，回表肯定是一行行搜索主键索引的基本流程如图 1所示这里查询的数据和索引的顺序是不一致的，比如a=1的时候查询的是L999，然后a=2是L998，这样就是随机读取，随机读取肯定是很慢的。

回表是指当使用索引进行查询时，首先根据索引定位到对应的行，然后需要再次通过行的物理位置进行读取，以获取该行的其他列数据。如果你创建了非聚簇索引（例如在"age"列上）并尝试根据"age"进行查询，当查询返回结果时，MySQL实际上会使用索引定位到"age"符合条件的行，然后再通过行的物理位置访问对应的"name"和"age"列数据。在MySQL数据库中，当使用非聚簇索引（如B树索引）进行查询时，如果需要获取查询结果行的其他列数据时，就可能发生回表（Look-up）操作。

并发问题：外键约束会启用行级锁，主表写入时会进入阻塞，假设我们我们买了十几样产品，然后在插入订单明细表的时候，每次都会检查订单表，在并发环境下 ，每次订单明细表去检查订单表的时候都会在订单表开启一个共享锁，假设操作订单明细表的时候，有人对订单表进行写入或者更新操作，那么就会加写锁，那么订单明细表就会处于阻塞状态，在外界表现来看就是订单明细表就会处于阻塞状态，长此以往就会造成线程积压，最后崩溃的现象。看下面这个表，假设我的订单表和订单明细表，这个会有什么问题呢？阿里的解析是不全面的，我们对其进行补充说明。

在 MySQL 数据库中，int 和 int(4) 都表示整数类型。总而言之，int 和 int(4) 在存储上没有区别，它们都表示相同的整数类型。int(4) 中的 (4) 表示显示宽度，用于指示客户端显示查询结果时保留的位数。如果要实现特定的显示效果，例如零填充，可以使用显示宽度和适当的附加属性（如 ZEROFILL）来控制查询结果的格式。

B+树叶子和非叶子结点的数据页都是16k，且数据结构一致，区别在于叶子节点放的是真实的行数据，而非叶子结点放的是主键和下一个页的地址。B+树一般有两到三层，由于其高扇出，三层就能支持2kw以上的数据，且一次查询最多1~3次磁盘IO，性能也还行。存储同样量级的数据，B树比B+树层级更高，因此磁盘IO也更多，所以B+树更适合成为mysql索引。索引结构不会影响单表最大行数，2kw也只是推荐值，超过了这个值可能会导致B+树层级更高，影响查询性能。单表最大值还受主键大小和磁盘大小限制。

转载：https://github.com/CyC2018/CS-Notes事务指的是满足 ACID 特性的一组操作，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。事务被视为不可分割的最小单元，事务的所有操作要么全部提交成功，要么全部失败回滚。回滚可以用回滚日志（Undo Log）来实现，回滚日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。数据库在事务执行前后都保持一致性状态。在一致性状态下，所有事务对同一个数据的读取结果都是相同的。一个事务所做的修改在最终

建议去看原文，人家原创不易，我也是学习防丢失。美团问数据库比较多，分享一位读者面试美团遇到的关于 MySQL 自增主键的问题。下面是正文。众所周知，自增主键可以让聚集索引尽量地保持递增顺序插入，避免了随机查询，从而提高了查询效率但实际上，MySQL 的自增主键并不能保证一定是连续递增的。

接下来我在网上搜，发现各种的解决都有，大部分都是通过设置更短的时间解决的，但是很少有说为什么设置的这么短就可以解决，而且每个人的数据库配置都是不一样的，所以实际上没什么借鉴意义。然后我在搜索的时候发现有一个结果是导向了GitHub的，我想到这个问题应该是很常见的，而且GitHub上作者也会那么我就到GitHub上HikariCP 的issue里面进行搜索，发现了这么一个issue，这个issue也有作者在里面回答，作者的回答主要是检查mysql的连接时间和是否有获取并自行关闭了底层的connection。

转载：MySQL 导出数据库 仅供自己学习。这篇文章有趣，我看的是A文章，然后A转载的是B，然后B转载的是C，然后C转载的是D。 我这里直接转载了D。主要是确实好用，在没有工具的情况下。MySQL备份和还原,都是利用mysqldump、mysql和source命令来完成的。 Server 5.0/bin”命令进入bin文件夹 | 利用导出数据库到文件，如然后输入密码即可开始导出。进入MySQL Command Line Client，输入密码，进入到，输入命令，回车，看看有些什么数据库；建立你要还原的

1.概述为了避免对源表加读锁，更稳妥的方案是先将数据写到外部文本文件，然后再写回目标表一种方法是，使用 mysqldump 命令将数据导出成一组 INSERT 语句另一种方法是直接将结果导出成.csv 文件。MySQL 提供语法，用来将查询结果导出到服务端本地目录：select * from db1.t where a>900 into outfile '/server_tmp/t.csv';得到.csv 导出文件后，你就可以用下面的 load data 命令将数据导入到目标表 db2.t 中.

在这个文章之前，我一直用count(1) 查询所有数据，以前我们都是说 count(*) 是最慢的。但是这个博客恰恰相反。对于来说，InnoDB 引擎会遍历整张表，把每一行的 id 值都取出来，返回给 server 层。server 层拿到 id 后，判断是不可能为空的，就按行累加。对于 count(1) 来说，InnoDB 引擎遍历整张表，但不取值。server 层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加。