【C++语言部分】总结篇 【操作系统】总结篇 【计算机网络】总结篇 【设计模式】总结篇

在数据库中，分页是指在查询结果集中按照一定的规则对数据集进行分割，每次获取部分数据集，而不是一次性获取所有数据。常见的用途是在Web应用程序中分页展示数据，以提高用户体验和性能。

MySQL的分页语法：

在MySQL中，SELECT语句默认返回所有匹配的行，它们可能是指定表中的每个行。为了返回第一行或前几行，可使用LIMIT子句，以实现分页查询。LIMIT子句的语法如下：

总之，带一个值的LIMIT总是从第一行开始，给出的数为返回的行数。带两个值的LIMIT可以指定从行号为第一个值的位置开始。

优化LIMIT分页：

在偏移量非常大的时候，例如 LIMIT 10000,20 这样的查询，这时MySQL需要查询10020条记录然后只返回最后20条，前面的10000条记录都将被抛弃，这样的代价是非常高的。如果所有的页面被访问的频率都相同，那么这样的查询平均需要访问半个表的数据。要优化这种查询，要么是在页面中限制分页的数量，要么是优化大偏移量的性能。

优化此类分页查询的一个最简单的办法就是尽可能地使用索引覆盖扫描，而不是查询所有的列，然后根据需要做一次关联操作再返回所需的列。对于偏移量很大的时候，这样做的效率会提升非常大。考虑下面的查询：

如果这个表非常大，那么这个查询最好改写成下面的样子：

这里的“延迟关联”将大大提升查询效率，它让MySQL扫描尽可能少的页面，获取需要访问的记录后再根据关联列回原表查询需要的所有列。这个技术也可以用于优化关联查询中的LIMIT子句。

有时候也可以将LIMIT查询转换为已知位置的查询，让MySQL通过范围扫描获得对应的结果。例如，如果在一个位置列上有索引，并且预先计算出了边界值，上面的查询就可以改写为：

对数据进行排名的问题也与此类似，但往往还会同时和GROUP BY混合使用，在这种情况下通常都需要预先计算并存储排名信息。

LIMIT和OFFSET的问题，其实是OFFSET的问题，它会导致MySQL扫描大量不需要的行然后再抛弃掉。如果可以使用书签记录上次取数的位置，那么下次就可以直接从该书签记录的位置开始扫描，这样就可以避免使用OFFSET。例如，若需要按照租赁记录做翻页，那么可以根据最新一条租赁记录向后追溯，这种做法可行是因为租赁记录的主键是单调增长的。首先使用下面的查询获得第一组结果：

假设上面的查询返回的是主键16049到16030的租赁记录，那么下一页查询就可以从16030这个点开始：

以上 SQL 查询将从 orders 表中选取 order_total 大于 1000 的记录。

例如，下面是一个使用 HAVING 语句的查询示例：

以上 SQL 查询将从 customers 表中选取 region 列，按照 region 列进行分组并计算每组中的行数。最终，仅保留行数大于 10 的分组，输出每个分组的 region 和行数（COUNT(*)）。

因此，WHERE 和 HAVING 语句的区别在于它们作用的范围不同。WHERE 仅能作用于筛选行，HAVING 仅能作用于分组筛选，它们分别在不同的执行阶段起作用，所以应该根据具体需求合理运用。

索引是一个单独的、存储在磁盘上的数据库结构，包含着对数据表里所有记录的引用指针。使用索引可以快速找出在某个或多个列中有一特定值的行，所有MySQL列类型都可以被索引，对相关列使用索引是提高查询操作速度的最佳途径。

索引是在存储引擎中实现的，因此，每种存储引擎的索引都不一定完全相同，并且每种存储引擎也不一定支持所有索引类型。MySQL中索引的存储类型有两种，即BTREE和HASH，具体和表的存储引擎相关。MyISAM和InnoDB存储引擎只支持BTREE索引；MEMORY/HEAP存储引擎可以支持HASH和BTREE索引。

索引的优点主要有以下几条：

增加索引也有许多不利的方面，主要表现在如下几个方面：

MySQL的索引可以分为以下几类：

使用CREATE TABLE创建表时，除了可以定义列的数据类型，还可以定义主键约束、外键约束或者唯一性约束，而不论创建哪种约束，在定义约束的同时相当于在指定列上创建了一个索引。创建表时创建索引的基本语法如下：

其中，UNIQUE、FULLTEXT和SPATIAL为可选参数，分别表示唯一索引、全文索引和空间索引；INDEX与KEY为同义词，两者作用相同，用来指定创建索引。

例如，可以按照如下方式，在id字段上使用UNIQUE关键字创建唯一索引：

在已经存在的表中创建索引，可以使用ALTER TABLE语句或者CREATEINDEX语句。ALTER TABLE创建索引的基本语法如下：

例如，可以按照如下方式，在bookId字段上建立名称为UniqidIdx的唯一索引：

CREATE INDEX创建索引的基本语法如下：

例如，可以按照如下方式，在bookId字段上建立名称为UniqidIdx的唯一索引：

在 MySQL 中，判断是否需要添加索引可以从以下几个方面进行考虑：

需要注意的是，虽然索引可以提高查询、排序和分组等操作的效率，但是过多的索引有可能会对写操作（INSERT、UPDATE、DELETE）性能造成影响，因此在选择是否需要添加索引时，需要充分考虑读写操作的平衡，权衡性能提升和空间占用等因素。

不一定。比如，在使用组合索引的时候，如果没有遵从“最左前缀”的原则进行搜索，则索引是不起作用的。

举例，假设在id、name、age字段上已经成功建立了一个名为MultiIdx的组合索引。索引行中按id、name、age的顺序存放，索引可以搜索id、（id,name）、（id, name, age）字段组合。如果列不构成索引最左面的前缀，那么MySQL不能使用局部索引，如（age）或者（name,age）组合则不能使用该索引查询。

可以通过以下方法判断数据库的索引是否生效：

可以通过 EXPLAIN 命令来分析查询语句的执行计划，从而判断索引是否被正确使用。例如，以下是查询 customers 表中 customer_name 列的语句：

执行上述命令后，可以得到一张表格，其中的 key 列显示了是否使用了索引。如果 key 列的值为 NULL，说明查询语句没有使用索引；如果 key 列的值为索引的名称，说明查询语句使用了该索引。

可以通过 SHOW INDEX 命令来查看表中所有索引的信息。例如，以下是查看 customers 表中索引信息的命令：

执行上述命令后，可以查看 customers 表中所有索引的名称、列、索引类型等信息。如果某个索引在使用中，其 Cardinality 值（表示该列的唯一值数量）将会比较大；如果 Cardinality 值为 1，则可能表示该索引没有被正确利用。

需要注意的是，通过以上方法可以初步判断索引是否生效，但是具体原因还需要进一步分析、排查。在实际使用中，可以通过 SQL 语句优化、索引设计和数据库性能工具等多种方式来检测和优化索引，提高查询效率。

建议按照如下的原则来设计索引：

索引并非越多越好，一个表中如有大量的索引，不仅占用磁盘空间，还会影响INSERT、DELETE、UPDATE等语句的性能，因为在表中的数据更改时，索引也会进行调整和更新。

可以采用以下几种方式，来避免索引失效：

不是。下列几种情况，是不适合创建索引的：

在 MySQL 中，索引的实现原理主要是使用 B-Tree（B-树）算法。B-Tree 是一种平衡的多叉树结构，它的特点是节点拥有多个子节点，能够在较快的时间内确定数据项的位置，具有较高的搜索和插入效率。

一个 B-Tree 索引由一个根节点、若干个中间节点和若干个叶子节点组成。其中，根节点和中间节点不包含数据，只包含索引值和指向子节点的指针；叶子节点包含索引值和具体数据行的指针。

当需要查询、添加、修改或删除数据时，MySQL 会首先在 B-Tree 索引的根节点上进行搜索。如果搜索的索引值在根节点中存在，则会继续在其对应的子节点中进行搜索，直到找到叶子节点，然后返回该数据行的指针；如果搜索的索引值在根节点中不存在，则终止搜索。

当需要向 B-Tree 索引中添加、修改或删除数据时，MySQL 也会先搜索到该数据行在 B-Tree 索引中的位置，然后进行相应的操作。

B-Tree 索引的实现原理使得 MySQL 能够高效地进行查找、插入、删除和修改等操作，并且能够适应不同的查询和数据变化。但是要注意，如果索引被滥用，也会增加数据的存储空间和降低数据的修改效率，因此需要在实现时进行合理的索引设计和优化。

什么时候需要重建索引呢

怎么判断索引是否应该重建

当查询的height>=4（索引的深度，即从根到叶节点的高度）或DEL_LF_ROWS/LF_ROWS>0.2的情况下，就应该考虑重建该索引。

如何重建索引

这种方式相当耗时，一般不建议使用。

此方法较快，建议使用。

rebuild是快速重建索引的一种有效的办法，因为它是一种使用现有索引项来重建新索引的方法。如果重建索引时有其他用户在对这个表操作，尽量使用带online参数来最大限度的减少索引重建时将会出现的任何加锁问题。由于新旧索引在建立时同时存在，因此，使用这种重建方法需要有额外的磁盘空间可供临时使用，当索引建完后把老索引删除，如果没有成功，也不会影响原来的索引。利用这种办法可以用来将一个索引移到新的表空间。

rebuild重建索引的过程：

重建索引过程中的注意事项：

B+树由B树和索引顺序访问方法演化而来，它是为磁盘或其他直接存取辅助设备设计的一种平衡查找树，在B+树中，所有记录节点都是按键值的大小顺序存放在同一层的叶子节点，各叶子节点通过指针进行链接。如下图：

MySQL 的索引采用 B+ 树的主要原因是 B+ 树拥有较高的读写效率和更好的数据范围扫描性能。 B+ 树是一种平衡树结构，它具有以下特点：

因此，B+ 树适用于需要大量范围查询和排序的场景，如 SQL 语句中的多个 ORDER BY 或 GROUP BY 子句、LIKE 关键字匹配和地理位置查找等。

相对于 B 树，B+ 树的优势在于拥有更好的读写效率和更容易维护平衡树高度。另外，由于 B+ 树中数据只存储在叶子节点上，因此可以更大限度地利用内存，提升查询效率。综合来看，B+ 树结构相对于 B 树结构更加适合作为MySQL的索引结构。

联合索引是指对表上的多个列进行索引，联合索引的创建方法与单个索引创建的方法一样，不同之处仅在于有多个索引列。从本质上来说，联合索引还是一棵B+树，不同的是联合索引的键值数量不是1，而是大于等于2，参考下图。另外，只有在查询条件中使用了这些字段的左边字段时，索引才会被使用，所以使用联合索引时遵循最左前缀集合。

hash索引底层就是hash表，进行查找时，调用一次hash函数就可以获取到相应的键值，之后进行回表查询获得实际数据。B+树底层实现是多路平衡查找树，对于每一次的查询都是从根节点出发，查找到叶子节点方可以获得所查键值，然后根据查询判断是否需要回表查询数据。它们有以下的不同：

因此，在大多数情况下，直接选择B+树索引可以获得稳定且较好的查询速度。而不需要使用hash索引。

聚簇索引和非聚簇索引是关系型数据库中常见的两种索引类型，它们的主要区别在于索引的存储方式和访问方式。

聚簇索引是将表的数据存储和索引存储结合在一起的索引方式。具体而言，聚簇索引将表的主键和数据存储在同一颗 B-Tree 中，因此称为聚簇（Clustered）索引。这意味着表的数据存储方式与聚簇索引的存储方式相关联。如果表中没有主键，则聚簇索引会隐式地将一个列或一组列作为主键。

非聚簇索引是将索引和表的数据存储分开的索引方式。它的索引和表的数据存储在不同的位置。非聚簇（Non-clustered）索引将索引叶子节点指向表的主键或唯一标识符，这样就可以通过索引快速地查找到表中的数据。

由于聚簇索引将表和索引数据存储在同一颗 B-Tree 中，因此查询聚簇索引时可以直接将数据读取到内存。这样可以提高查询效率，同时也意味着聚簇索引并不是很适合频繁进行插入、更新和删除操作的表，因为这些操作会导致树的重构。

非聚簇索引由于和表的数据存储分开，因此可以适用于频繁进行插入、更新和删除操作的表。同时，由于非聚簇索引在查询时需要进行两次查找（一次查找索引，一次查找实际数据），因此相对于聚簇索引查询需要更多的 IO 操作，这可能会导致非聚簇索引的查询效率相对较低。

索引是否起作用，主要取决于字段类型：

IN的字段，在联合索引中，按以上方法，也会起作用。

在MySQL中模糊查询 mobile like ‘%8765’ ，这种情况是不能使用 mobile 上的索引的，那么如果需要根据手机号码后四位进行模糊查询，可以用一下方法进行改造。

我们可以加入冗余列（MySQL5.7之后加入了虚拟列，使用虚拟列更合适，思路相同），比如 mobile_reverse，内部存储为 mobile 的倒叙文本，如 mobile为17312345678，那么 mobile_reverse 存储 87654321371，为 mobile_reverse 列建立索引，查询中使用语句 mobile_reverse like reverse(’%5678’) 即可。

reverse 是 MySQL 中的反转函数，这条语句相当于 mobile_reverse like ‘8765%’ ，这种语句是可以使用索引的。

数据库事务是指一系列的数据库操作（增、删、改），这些操作要么全部执行成功，要么全部失败回滚，保证数据库的一致性和完整性。数据库事务具有以下四个特性（ACID）：

为了实现事务的隔离性，数据库采用了一些隔离级别，包括 read uncommitted、read committed、repeatable read 和 serializable。不同的隔离级别提供了不同的并发控制机制，确保事务之间的隔离性。

总之，数据库事务通过保证一系列数据库操作的一致性和完整性，提供了数据库操作的可靠和安全性。

事务可以分为以下几种类型：

对于MySQL的InnoDB存储引擎来说，它支持扁平事务、带有保存点的扁平事务、链事务、分布式事务。对于嵌套事务，MySQL数据库并不是原生的，因此对于有并行事务需求的用户来说MySQL就无能为力了，但是用户可以通过带有保存点的事务来模拟串行的嵌套事务。

MySQL 作为一种关系型数据库，支持事务及 ACID 特性，具体实现如下：

总之，MySQL 通过使用 redo log、undo log、约束、触发器、隔离级别、锁机制以及日志记录等机制，保证了事务的 ACID 特性，为数据库操作提供了可靠和安全的支持。

MySQL 支持四种事务隔离级别，分别为 READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和 SERIALIZABLE。不同的隔离级别会使用不同的锁机制和并发控制方式，以确保事务之间的隔离性和数据一致性。具体介绍如下：

MySQL 的事务隔离级别主要依赖于锁和 MVCC 机制来实现，具体实现如下：

可以，因为嵌套事务也是众多事务分类中的一种，它是一个层次结构框架。有一个顶层事务控制着各个层次的事务，顶层事务之下嵌套的事务被称为子事务，它控制每一个局部的变换。 需要注意的是，MySQL数据库不支持嵌套事务。

MySQL的InnoDB引擎，在默认的REPEATABLE READ的隔离级别下，实现了可重复读，同时也解决了幻读问题。它使用Next-Key Lock算法实现了行锁，并且不允许读取已提交的数据，所以解决了不可重复读的问题。另外，该算法包含了间隙锁，会锁定一个范围，因此也解决了幻读的问题。

MySQL的InnoDB引擎，在默认的REPEATABLE READ的隔离级别下，实现了可重复读，同时也解决了幻读问题。它使用Next-Key Lock算法实现了行锁，并且不允许读取已提交的数据，所以解决了不可重复读的问题。另外，该算法包含了间隙锁，会锁定一个范围，因此也解决了幻读的问题。

在MySQL默认的配置下，事务都是自动提交和回滚的。当显示地开启一个事务时，可以使用ROLLBACK语句进行回滚。该语句有两种用法：

数据库锁是为了保证数据多用户并发操作时的安全性而引入的一种机制。数据库锁主要分为两类：行级锁和表级锁。

除了基础锁机制之外，数据库还提供了其他类型的锁来保证数据一致性，如：间隙锁（Gap Lock）、意向锁（Intention Lock）等。 总之，数据库锁是为了保证数据多用户并发操作时的安全性而引入的一种机制，可分为行级锁和表级锁。在使用锁机制时，需要根据具体情况选择合适的锁粒度和锁类型，以保证数据操作的正确性和高效性。

InnoDB存储引擎有3种行锁的算法，间隙锁（Gap Lock）是其中之一。间隙锁用于锁定一个范围，但不包含记录本身。它的作用是为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生。

InnoDB行级锁是通过给索引上的索引项加锁来实现的。只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。

当表中锁定其中的某几行时，不同的事务可以使用不同的索引锁定不同的行。另外，不论使用主键索引、唯一索引还是普通索引，InnoDB都会使用行锁来对数据加锁。

数据库死锁是指多个事务在同时请求锁资源时出现循环依赖，导致所有事务都被阻塞，无法继续执行的情况。数据库死锁一般发生在以下情况：

为避免数据库死锁问题，可以采取以下措施：

解决死锁问题最简单的一种方法是超时，即当两个事务互相等待时，当一个等待时间超过设置的某一阈值时，其中一个事务进行回滚，另一个等待的事务就能继续进行。

除了超时机制，当前数据库还都普遍采用wait-for graph（等待图）的方式来进行死锁检测。较之超时的解决方案，这是一种更为主动的死锁检测方式。InnoDB存储引擎也采用的这种方式。wait-for graph要求数据库保存以下两种信息：

通过上述链表可以构造出一张图，而在这个图中若存在回路，就代表存在死锁，因此资源间相互发生等待。这是一种较为主动的死锁检测机制，在每个事务请求锁并发生等待时都会判断是否存在回路，若存在则有死锁，通常来说InnoDB存储引擎选择回滚undo量最小的事务。

MySQL数据库优化是多方面的，原则是减少系统的瓶颈，减少资源的占用，增加系统的反应速度。例如，通过优化文件系统，提高磁盘I\O的读写速度；通过优化操作系统调度策略，提高MySQL在高负荷情况下的负载能力；优化表结构、索引、查询语句等使查询响应更快。

针对查询，我们可以通过使用索引、使用连接代替子查询的方式来提高查询速度。

针对慢查询，我们可以通过分析慢查询日志，来发现引起慢查询的原因，从而有针对性的进行优化。

针对插入，我们可以通过禁用索引、禁用检查等方式来提高插入速度，在插入之后再启用索引和检查。

针对数据库结构，我们可以通过将字段很多的表拆分成多张表、增加中间表、增加冗余字段等方式进行优化。

如果查询时没有使用索引，查询语句将扫描表中的所有记录。在数据量大的情况下，这样查询的速度会很慢。如果使用索引进行查询，查询语句可以根据索引快速定位到待查询记录，从而减少查询的记录数，达到提高查询速度的目的。 索引可以提高查询的速度，但并不是使用带有索引的字段查询时索引都会起作用。有几种特殊情况，在这些情况下有可能使用带有索引的字段查询时索引并没有起作用。

使用子查询可以进行SELECT语句的嵌套查询，即一个SELECT查询的结果作为另一个SELECT语句的条件。子查询可以一次性完成很多逻辑上需要多个步骤才能完成的SQL操作。

子查询虽然可以使查询语句很灵活，但执行效率不高。执行子查询时，MySQL需要为内层查询语句的查询结果建立一个临时表。然后外层查询语句从临时表中查询记录。查询完毕后，再撤销这些临时表。因此，子查询的速度会受到一定的影响。如果查询的数据量比较大，这种影响就会随之增大。

在MySQL中，可以使用连接（JOIN）查询来替代子查询。连接查询不需要建立临时表，其速度比子查询要快，如果查询中使用索引，性能会更好。

影响插入速度的主要是索引、唯一性校验、一次插入记录条数等。针对这些情况，可以分别进行优化。 对于MyISAM引擎的表，常见的优化方法如下：

对于InnoDB引擎的表，常见的优化方法如下：

建议按照如下顺序进行优化：

慢查询是指执行时间超过阈值（默认为10秒）的 SQL 查询语句，通常情况下这些查询语句会给数据库带来很大的压力，影响系统的性能和稳定性，因此需要对慢查询进行优化。下面是一些 MySQL 慢查询优化的方法：

总之，MySQL 慢查询优化需要综合考虑索引优化、SQL 语句优化、数据库服务器优化、分区表、查询执行顺序等多种因素，根据实际情况进行优化，以提高查询效率和减少响应时间。

MySQL中提供了EXPLAIN语句和DESCRIBE语句，用来分析查询语句，EXPLAIN语句的基本语法如下：

使用EXTENED关键字，EXPLAIN语句将产生附加信息。执行该语句，可以分析EXPLAIN后面SELECT语句的执行情况，并且能够分析出所查询表的一些特征。下面对查询结果进行解释：

EXPLAIN 是 MySQL 中的一个关键字，用于将一个 SELECT 查询语句转化为可读的执行计划（execution plan）。执行计划是分析查询语句时，MySQL 对优化器进行的解释，展示了 MySQL 如何解析一个查询的每个组成部分，并从哪些表中获取数据、使用哪些索引、排序方式和连接方式。EXPLAIN 所提供的信息可以帮助我们更好地理解和优化查询语句。在使用 EXPLAIN 时，应该关注以下几个方面：

通过分析 EXPLAIN 的执行计划，我们可以明确查询语句中的瓶颈，并对索引、表结构和查询方式等进行优化，从而提高查询效率。

数据库设计的三大范式（Normalization）是一种设计方法，旨在将重复数据以及数据不一致性等问题最小化，并提高数据的可靠性和完整性。这三个范式依次为：

MySQL 支持多个存储引擎（storage engine），不同的存储引擎对于数据的处理方式和性能表现是不同的，可以根据需求选择不同的存储引擎进行使用，常见的存储引擎包括：

在 MySQL 中，有三个常见的日志文件类型，分别是 redo log、undo log 和 binlog。

InnoDB默认的隔离级别是RR（REPEATABLE READ），RR解决脏读、不可重复读、幻读等问题，使用的是MVCC。MVCC全称Multi-Version Concurrency Control，即多版本的并发控制协议。它最大的优点是读不加锁，因此读写不冲突，并发性能好。InnoDB实现MVCC，多个版本的数据可以共存，主要基于以下技术及数据结构：

MySQL 主从同步是一种将主数据库中的数据自动同步到从数据库中的机制，这种机制可以提升数据的冗余性和可用性，同时在读写分离的架构中也有广泛应用。 复制（replication）是MySQL数据库提供的一种高可用高性能的解决方案，一般用来建立大型的应用。总体来说，replication的工作原理分为以下3个步骤：

复制的工作原理并不复杂，其实就是一个完全备份加上二进制日志备份的还原。不同的是这个二进制日志的还原操作基本上实时在进行中。这里特别需要注意的是，复制不是完全实时地进行同步，而是异步实时。这中间存在主从服务器之间的执行延时，如果主服务器的压力很大，则可能导致主从服务器延时较大。复制的工作原理如下图所示，其中从服务器有2个线程，一个是I/O线程，负责读取主服务器的二进制日志，并将其保存为中继日志；另一个是SQL线程，复制执行中继日志。