干就完了！！！

Oracle从12c版本开始引入了多租户架构，也就是CDB（容器数据库） + PDB（可插拔数据库）的结构。租户对应​​可插拔数据库（PDB）​​，代表一个独立的数据库实例。所有的这些租户构成了整个容器数据库（CDB）。一个租户又可以包含一个或多个用户，每个用户对应一个模式，而模式可以看做是一个容器，这个容器中包含了各种数据库实体对象，比如表、视图、存储过程等。

执行 SQL 语句执行 SQL 脚本可以同时执行的 SQL 数量执行单个 SQL执行多个 SQL报错信息是否能定位到行否能建议直接采用 “执行 SQL 脚本” 这种方式。

类型前缀为 “N” 代表使用的是国家字符集，且字符存储时采用 Unicode，且在多语言情况下相同字符所需的存储空间可能更小。类型前缀不带 “N” 代表采用数据库默认的字符集，可能会导致字符存储时不采用 Unicode 编码方式。但一般数据库默认的字符集都是 UTF8 类型的。因此一般用不带 “N” 的类型就可以了。前缀带 “N” 的类型长度 M 代表的都是字符长度，不带 “N” 的类型长度 M 默认都是指字节长度。查看当前数据库默认字符集和国家字符集的方式如下：输出为：可以看到此时默认字符集为 AL

undo log：记录的是逻辑日志，比如对某一行数据进行了 insert 操作，那么 undo log 就记录一条与之相反的 delete 操作；redo log：记录的是物理日志，记录了某个数据页做了什么修改，比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新；binlog：记录的是逻辑日志，记录内容是语句的原始逻辑，类似于 “给 ID=2 这一行的 c 字段加 1”；undo log：①用于事务的回滚，保证事务的原子性；②用于 MVCC，实现事务的隔离性；

InnoDB 的表级锁比较鸡肋，一般不会被用到，重点在于理解 InnoDB 的行级锁。悲观锁：悲观锁是一种思想，顾名思义，就是很悲观，对数据被其他事务的修改持保守态度，会通过数据库自身的锁机制来实现，从而保证数据操作的排它性。悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会锁，这样别人再去操作这个数据时就会被阻塞直到它拿到锁（比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起。

​ 如果我们的一些业务场景不允许读取记录的旧版本，而是每次都必须去读取记录的最新版本，比方在银行存 款的事务中，你需要先把账户的余额读出来，然后将其加上本次存款的数额，最后再写到数据库中。在将账 户余额读取出来后，就不想让别的事务再访问该余额，直到本次存款事务执行完成，其他事务才可以访问账 户的余额。这样在读取记录的时候也就需要对其进行加锁操作，这样也就意味着读操作和写操作也像写-写操 作那样排队执行。所以在多个事务相继对同一条记录进行写操作的时候，需要让他们排队执行，这个过程是通过在内存中创建一个。

与之对应的是「基于索引统计数据」来预估记录条数，一般是发生在使用 IN 进行范围查询，且 IN 里面的条件较多时。，然后再计算这两条记录之间有多少记录（记录条数少的时候可以做到精确计算，多的时候只能估算）。如果是走索引，则需要计算需要回表的记录数量，来计算 CPU 成本。记录数量的计算方式为：先获取索引对应的。表的成本常数，可以引导 MySQL 去生成倾向于全表扫描或倾向于搜索索引的执行计划。这里的扇出数实际上就是驱动表经过条件过滤后剩余的记录数。树来计算某个范围区间对应的索引记录条数的方式称之为。

是数据库查询优化中的一种技术，它将查询中的（通常是WHERE子句、JOIN条件等）尽早地应用到或的过程中（这个过程即），以减少需要处理的数据量，从而提高查询效率。谓词下推的目标是通过在数据访问的早期阶段就过滤不必要的数据，避免从数据源加载大量不符合条件的行，最终减少 I/O 操作和提高性能。优化过程：如果表employees是一个大表，数据库优化器会将这个谓词推到扫描操作之前。优化后的执行计划会首先扫描employees表，并且只读取满足条件的行。优化器推导出查询不需要加载。

物化视图与普通视图的主要区别在于：

对于需要频繁更新的字段，建议用普通索引，因为他能通过使用来提升更新表的性能。此外，如果所有的更新后面，都马上伴随着对这个记录的查询 ，那么你应该关闭。如果数据需要保证唯一性，但业务无法保证，即需要数据库来保证唯一性。那为了业务的正确性，就必须要用唯一索引。对于联表查询的情况，可以考虑将被驱动表的连接字段设置为唯一索引，因为 InnoDB 在选择执行计划前会去计算成本，而唯一索引的成本一般被认为是更低的，那生成的执行计划就会更加偏向于走索引。

覆盖索引一般是针对二级索引而言的，我们知道二级索引的叶子节点存储了索引列 + 主键 id的信息。当叶子节点包含了满足查询结果的所有数据，那么这个二级索引就被称为覆盖索引。此时，不再需要回表去查询其他列的信息，因此性能较高。key2 INT,-- 由于联合索引 idx_key_part 包含了 key_part1, key_part2 的完整记录，因此不需要回表。我们称它为覆盖索引。

在这个例子中，ON 子句用于指定连接条件，并且立即应用这个条件。结果集将包含所有学生，无论他们是否选修了数学课。下面通过两个例子来说明，这两个例子将展示不同的结果集。时，对应的学生记录才会被包含在结果集中。因此，结果集将只包含那些选修了数学课的学生，未选修数学课的学生不会出现在结果集中。如果上面使用的是内连接（Inner Join），那结果就是一致的了。未选修数学课的学生也会出现在结果集中，只是对应的。现在，我们使用相同的表，但是这次我们将选课条件放在。子句用于过滤连接后的结果集。

首先，我们创建两个表t1和t2，这两个表都有一个主键索引 id 和一个索引 a，字段 b 上无索引。存储过程 idata() 往表t2里插入了 1000 行数据，在表t1里插入的是 100 行数据。delimiter;;set i=i+1;end while;end;;delimiter;对于下面的 SQL 语句，由于t2表只需要取前 50 行，因此认为t2为小表。在下面的例子中，表t1和t2都是只有 100 行参加join，但是表t1。

如果开发者理解索引条件下推的原理，就可以主动引导优化器选择走索引的访问方法（当然了，走索引快还是不走索引快，得经过实测）。我们可以发现，ICP 通过用联合索引中的多个列作为过滤条件，减少了需要回表的记录数，减少了返回给 server 层的记录数，从而优化了查询效率。将回表得到的完整记录返回给 server 层，并在 server 层按其他条件做进一步过滤。的一种优化方式，可以减少在存储引擎层回表的次数，减少返回给 server 层的数据量。作为过滤条件，在联合索引树中找到符合条件的记录。

遵守数据库范式可以帮我们减少数据冗余、更好地保证数据一致性。目前关系型数据库有六种常见范式，按照范式级别，从低到高分别是：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。高级别的范式一定遵守低级别的范式，比如满足 3NF 的表一定满足 1NF 和 2NF。越高级别的范式代表更少的冗余，也往往对应着更多的联表查询，因此一般我们遵守到 3NF 即可。且为了提升数据查询的效率，可以考虑使用反范式化。

本文介绍慢查询的优化思路，但不以索引优化作为重点，索引相关的优化可以参考。

具体实现方式是：在 SQL 执行过程中，第一次需要子查询结果时执行子查询并将子查询的结果保存为临时表（一般情况下优化器就会帮我们做这件事） ，后续对子查询结果集的访问将直接通过临时表获得。假设我们有一个学生表 student 和班级表 class，学生表记录了学生的学号 stu_no，而班级表记录了班级信息以及每个班级的班长的学号 monitor_no。此时，整个查询的执行逻辑不再是像我们想象的一样：先执行子查询获取到一个小的结果集，然后以这个小结果集在 g1 中作为过滤条件去过滤。

虽然索引能带来查询上的效率，但是维护索引的成本也是不小的。如果一个字段不被经常查询，反而被经常修改，那么就更不应该在这种字段上建立索引了。因为索引是需要占用磁盘空间的，可以简单理解为每个索引都对应着一颗 B+树。如果一个表的字段过多，索引过多，那么当这个表的数据达到一个体量后，索引占用的空间也是很多的，且修改索引时，耗费的时间也是较多的。如果是联合索引，多个字段在一个索引上，那么将会节约很大磁盘空间，且修改数据的操作效率也会提升。此外，使用多列索引时，选择性强（字段的重复值越低，选择性越强）的放左边。。

本文针对 MySQL 单表查询时索引使用的几种场景情况进行分析。

根据具体的场景选择批量更新的方法。此外，在批处理的时候需要考虑一下事务的问题。

根据具体的场景选择批量插入方法。此外，在批处理的时候需要考虑一下事务的问题。

一般情况下 SQL 执行的优先级从高到低依次是：1.from2.on3.join4.where5.group by6.聚合函数7.having8.select9.distinct11.limit。

一个事务对某条记录进行读操作时，会查看这一条记录的一系列事务 id（由 undo log 构成的版本链中的事务 id），并根据事务的隔离级别（“读已提交”、“可重复读”）去选择生成 Read View 的方式，通过比较事务 id 来确定可见的版本。下图记录了某一行数据的变更过程，图中虚线框里是同一行数据的 4 个版本，当前最新版本是 V4，k 的值是 22，它是被 transaction id 为 25 的事务更新的，因此它的 row trx_id 也是 25。用来存储“活跃”的事务的 id。

WHY：锁的出现是为了解决并发场景下不同用户同时对共享资源进行操作，而可能引发的并发问题。HOW：控制不同线程对资源访问的规则。

本文为笔者学习林晓斌老师《MySQL 实战 45 讲》课程的学习笔记，并进行了一定的知识扩充。

中的 50 在 mysql5.0 及以上默认是存储的字符数，5.0 以下，默认是字节长度。

本文未做特别说明的，指同时适用于 MySQL 5.7 和 MySQL 8.x。