Mysql

MySQL 重要内容整理（高性能 MySQL）

MySQL 基础架构

• 最上层的客户端所包罗的服务并不是 MySQL 独有的，大多数基于网络的客户端/服务器工具或服务器都有类似的服务，包罗连接处理、身份验证、确保安全性等。
  
• 第二层包罗了大多数 MySQL 的焦点功能，包罗查询解析、分析、优化、以及所有的内置函数（例如，日期、时间、数学和加密函数），所有跨存储引擎的功能也都在这一层实现：存储过程、触发器、视图等。
  

  在旧版本中，MySQL 可以使用内部查询缓存（query cache）来查看是否可以直接提供结果。但是，随着并发性的增加，查询缓存成为一个让人诟病的瓶颈。从 MySQL 5.7.20 版本开始，查询缓存已经被官方标注为被弃用的特性，并在 8.0 版本中被完全移除。
  

  
  
• 第三层是存储引擎层。存储引擎负责 MySQL 中数据的存储和提取。存储引擎层还包罗几十个底层函数，用于执行诸如“开始一个事件”大概“根据主键提取一行记载”等操作。但存储引擎不会去解析 SQL，不同存储引擎之间也不会相互通信，而只是简单地相应服务器的请求。
  

并发控制

• 锁
  

• 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最
  高，并发度最低。
  
• 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最
  低，并发度也最高。
  
• 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表
  锁和行锁之间，并发度一般
  

Innodb 默认支持行级锁，相比于 MyISAM 的表级锁而言更加精致，对于并发事件的读写而言性能更高，行级锁的分类分为：间隙锁，临键锁，记载锁，
处理并发读/写访问的系统通常实现一个由两种锁类型组成的锁系统。这两种锁通常被称为共享锁（shared lock）和排他锁（exclusive lock），也叫读锁（read lock）和写锁（write lock）。其中资源上的读锁是共享的，大概说是相互不壅闭的。多个客户端可以同时读取同一个资源而互不干扰。写锁则是排他的，也就是说，一个写锁既会壅闭读锁也会壅闭其他的写锁。
锁定策略是锁开销和数据安全性之间的平衡，这种平衡会影响性能

• 表锁
  表锁（table lock）是 MySQL 中最基本也是开销最小的锁策略。它会锁定整张表。当客户端想对表进行写操作（插入、删除、更新等）时，需要先得到一个写锁，这会壅闭其他客户端对该表的所有读写操作。只有没有人执行写操作时，其他读取的客户端才能得到读锁，读锁之间不会相互壅闭。
  
• 行锁
  使用行级锁（row lock）可以最大程度地支持并发处理（也带来了最大的锁开销）。行锁只锁定特定行而不影响其他行的读写操作，但系统也需要花费更多的开销监控这些行级锁、锁定的时间、锁定类型以及何时清理不需要的行锁。行级锁是在存储引擎而不是服务器中实现的
  
• 事件
  事件就是一组 SQL 语句，作为一个工作单元以原子方式进行处理，事件中的那些语句要么全部执行要么全部失败。事件遵循 ACID 特性

  事件的实现：事件隔离性由锁来实现。原子性、致性、持久性通过数据库的 redolog 和 undo log 来完成。redo log 称为重做日志，用来包管事件的原子性和持久性。
  

  
  
• 日志
  重做日志用来实现事件的持久性，即事件 ACID 中的 D。
  其由两部分组成：
  一是内存中的重做日志缓冲（redo log buffer），其是易失的；
  二是重做日志文件（redo log file），其是持久的。
  

多版本并发控制

• 隔离级别：
  
  
  
  READ UNCOMMITTED（读未提交）在事件中可以查看其他事件中还没有提交的修改
  读取未提交的数据，也称为脏读
  READ COMMITTED（读已提交）B 事件只能看到 A 事件提交之后的数据和修改。这个级别会产生不可重复读问题，由于 B 事件在 A 事件修改前后读取的数据可能会不一致，这意味着同一事件中两次执行相同语句，可能会看到不同的数据结果
  REPEATABLE READ（可重复读）MYSQL 默认隔离级别，包管了在同一个事件中多次读取相偕行数据的结果是一样的，解决了不可重复读问题。但不能解决幻读：当 A 事件在读取某个范围内的记载时，另外一个事件 B 又在该范围内插入了新的记载，当 A 事件再次读取该范围的记载时，会产生幻行。
  SERIALIZABLE（可串行化）
  

幻读：可重复读隔离级别下，是存在幻读的问题：
Innodb 引擎为相识决「可重复读」隔离级别下的幻读问题，就引出了 next-key 锁，它是记载锁和间隙锁的组合。
Record Lock，记载锁，锁的是记载自己；
Gap Lock，间隙锁，锁的就是两个值之间的空隙，以防止其他事件在这个空隙间插入新的数据，从而制止幻读现象。

innodb MVCC 重要是为 Repeatable-Read 事件隔离级别做的。在此隔离级别下，A、B 客户端所示的数据相互隔离，互相更新不可见
MVCC 是行锁的变种，他在很多时候制止了加锁操作，大多时候可以实现非壅闭的读操作，写操作也只锁定特定的行因此精致度更好，开销更低。
MVCC 的实现是通过保存数据的某个时间点的快照来实现的，因此不管执行多长时间，每个事件看到的数据都是一致的。根据事件开始的时间不同，每个事件对同一张表，且同一时刻看到的数据是不一样的。
InnoDB 中的 MVCC 设计： 在每条记载背面保存两个隐藏的列来实现，保存了行的创建时间和行的逾期时间。（实际存储时候将系统版本号替换时间）每开始一个事件系统版本号会主动递增。
SELECT
确定行创建时间： InnnoDB 查找版本早于当前的事件版本的数据行，以确保当前事件读取的数据不晚于当前事件开始时间，
确定行删除时间：要么行删除版本未定义要么大于当前事件开始时间，确保事件读取的行在事件开始之前存在

确定了行创建时间和删除时间均符合要求才能够进行返回结果；

INSERT
新插入的每一行保存当前系统版本号作为行版本号
DELETE
删除的每一行保存当前的系统版本号作为行删除版本号
UPDATE
插入一行新的记载，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为删除标识。
https://pdai.tech/md/db/sql-mysql/sql-mysql-mvcc.html
索引

说一下索引实现

MySQL 的默认存储引擎是 InnodB,innodb 默认的索引结构为 B+树，B+树只有叶子节点才存储数据，非叶子节点存储键值，指向了索引的方向。叶子节点的结构为双向有序的数据链表，因此他可以进行范围查找。同时 B+树一个节点可以存储多个孩子，使得 B+树显得更加矮胖，从而 B+树可以减少磁盘的查询次数并且不同于平凡的二叉树，只需要遍历一次就可以得到所有的叶子数据，从而进步查找效率。
为什么使用 B+树

B+树：只有叶子节点才会存储数据，非叶子节点只存储键值，指向索引方向。叶子节点之间使用双向指针连接，最底层的叶子节点形成了一个双向有序链表,可以进行范围查找，同时为了维护底层叶子的有序性，在插入和删除时候需要对索引进行维护涉及到页面分裂和页面归并等操作。

为什么不用平凡二叉树？

平凡二叉树存在退化的情况，如果它退化成链表，相称于全表扫描。平衡二叉树相比于二叉查找树来说，查找效率更稳固，总体的查找速率也更快。

为什么不用平衡二叉树呢？

平衡二叉树每个节点只存储一个键值和数据的，B+树可以存储多个，同时树的高度也会更低那么对应的查找磁盘的次数也会少，

为什么用 B+ 树而不用 B 树呢

B+Tree 的磁盘读写能力相对于 B Tree 来说更强，IO 次数更少，B+Tree 永远是在叶子节点拿到数据，不需要遍历整个树就能拿到所有数据，以是 IO 次数是稳固的，叶子节点按照顺序排序，B+树的排序能力更强
Innodb 索引

索引，在 MySQL 中也叫作键（key）
优点：
● 索引大大减少了服务器需要扫描的数据量。
● 索引可以资助服务器制止排序和暂时表。
● 索引可以将随机 I/O 变为顺序 I/O。

• 分类
  B-Tree；B-tree 通常意味着所有的值都是按顺序存储的，并且每一个叶子页到根的间隔相同。B-tree 是按照索引列中的数据大小顺序存储的，以是很适合按照范围来查询
  

索引类型分为主键索引（聚簇索引）和非主键索引（二级索引）。

非叶子节点包罗了索引列和一个指向下级节点的指针

• 聚簇索引：聚簇索引的叶子节点存的是整行数据。术语“聚簇”表现数据行和相邻的键值紧凑地存储在一起。由于无法同时把数据行存放在两个不同的地方，以是一个表只能有一个聚簇索引（不外，覆盖索引可以模拟多个聚簇索引的情况）。InnoDB 根据主键聚簇数据，如果你没有定义主键，InnoDB 会选择一个唯一的非空索引代替。如果没有如许的索引，InnoDB 会隐式定义一个主键来作为聚簇索引。
  
• 二级索引：非主键索引的叶子节点内容是主键的值。这意味着通过二级索引查找行，存储引擎需要找到二级索引的叶子节点，以得到对应的主键值，然后根据这个值去聚簇索引中查找对应的行。这里做了双倍工作：两次 B-tree 查找而不是一次。使用主键值作为指针会
  让二级索引占用更多的空间，换来的好处是，InnoDB 在移动行时无须更新二级索引中的
  这个“指针”。
  

索引的主键不要使用 UUID 如许随机的主键值，它使得插入变得完全随机，且数据自己没有聚簇特性 。写入的数据不能按照顺序进行插入，需要泯灭大量时间寻找合适的位置，且可能导致频繁的页分裂

使用 InnoDB 时应该尽可能地按主键顺序插入数据，并且尽可能地按照单调增加的聚簇键的值顺序插入新记载。

覆盖索引

覆盖索引不等同于二级索引

如果一个索引包罗（大概说覆盖）所有需要查询的字段的值，我们就称之为覆盖索引，即不需要进行回表操作。在一个覆盖索引中，如果索引是针对 (age, id, username) 创建的，那么叶子节点存储了按照 age 排序的索引列值，并且还包罗了每个索引行对应的 id 和 username 列的值。当执行覆盖查询时，数据库引擎可以直接从这些叶子节点中获取所有需要的列值，从而制止了额外的数据页访问，进步了查询效率。

EXPLAIN 的 Extra 列可以看到“Using index”的信息，表现使用了覆盖索引

索引分类

根据叶子的内容索引分为主键索引和非主键索引（只在叶子节点存放主键信息）

如果我执行 select * from T where k between 3 and 5，需要执行频频树的搜索操作，会扫描多少行？其中 k 黑白聚簇索引

• 查询过程
  现在非聚簇索引中查找 3 得到对应的主键，到聚簇索引中找到主键对应的行数据（第一次回表）
  现在非聚簇索引中查找 5 得到对应的主键，到聚簇索引中找到主键对应的行数据（第二次回表）
  在 k 索引树取下一个值 k=6，不满足条件，循环结束(第三次查询)。

  可以看到，这个查询过程读了 k 索引树的 3 条记载，回表了两次。在这个例子中，由于查询结果所需要的数据只在主键索引上有，以是不得不回表。
  

  
  

索引创建的注意

• 索引建立在查询频繁的字段上
  
• 维护索引需要成本，索引的数目应该合适
  
• 选择区分度高的字段作为索引
  
• 组合索引时将区分度高的放在前面
  
• 需要频繁更新的字段不适合作为索引
  
• 不建议用无序的值(例如身份证、UUID )作为索引
  

.优化器怎么去看索引的区分度
一条语句可能掷中多个索引，而优化器会选择合适的索引以最小的代价执行命令，我们使用 show index from table 可以查看索引的基数，即 Cardinality 字段的数字，基数越大反应了索引的区分度越大

索引优化

• sql 语句修改为select ID from T where k between 3 and 5，这时只需要查 ID 的值，而 ID 的值已经在 k 索引树上了，因此可以直接提供查询结果，不需要回表。也就是说，在这个查询里面，索引 k 已经“覆盖了”我们的查询需求，我们称为覆盖索引，制止了回表。
  
• 由于覆盖索引可以减少树的搜索次数，显著提升查询性能，以是使用覆盖索引是一个常用的性能优化手段。

  索引下推优化能减少回表查询次数，进步查询效率。
  索引下推的下推其实就是指将部分上层（Server 层）负责的事情，交给了下层（引擎层）行止理。使用索引下推当被索引的列为判断条件时，先一步 过滤出符合条件的数据没，减少了回表的次数，Innodb 索引的数据和索引在一起不存在回表，也就是说只有二级索引可以使用索引下推
  

  
  

范式

当一个查询语句同时出现了 where、group by、having 和 order by 、join 时，执行顺序如下

查表- 选字段 - 对字段分组- 过滤-筛选-排序

• from join 先执行得到关联的表
  
• WHERE 子句：首先执行 WHERE 子句，提取满足条件的记载。
  
• GROUP BY 子句：然后按照 GROUP BY 子句中指定的列进行分组，一般联合分组聚合函数 COUNT、MAX、SUM 等在 select 中对分组进行过滤。
  
• HAVING 子句：分组后接着使用 HAVING 子句进行过滤保留符合条件的分组。
  
• SELECT 子句：接着执行 SELECT 子句，选择需要表现的列。
  
• ORDER BY 子句：最后根据 ORDER BY 子句中指定的列对结果进行排序。

  having 只能用在 group by 之后
  where 肯定在 group by 之前
  注意若选取的列名和关键字相同 用""包起来表现别名
  

  
  

一条 SQL 查询语句在 MySQL 中如何执行的

• 查询缓存：连接器和客户端建立连接后，查询数据库缓存，如果之间执行过同样的语句则直接从内存中读取结果（执行缓存失效的情况非常频繁，MySQL8.0 后取消 ）
  
• 词法分析：没有掷中缓存，将解析 sql 语句为执行做准备，需要先用分析器进行词法和语法分析，判断语句是否正确。
  
• 优化器优化：将正确的 sql 语句进行优化，如是否使用索引，查询表的顺序等等
  
• 执行：最后通过执行器去执行语句，返回执行结果
  

MySql 的存储引擎

mysql 重要分为两种存储引擎，分别是 MylSAM 和 Innodb。两者的区别在于 MyIsm 只支持表锁且索引的为非聚簇索引结构为 B 树，而 innodb 引擎支持行锁，且支持聚簇索引，innodb 索引结构为 B+树
如何查看执行计划

https://tobebetterjavaer.com/sidebar/sanfene/mysql.html#_26-怎么看执行计划-explain-如何理解其中各个字段的含义
执行计划中的 key 列表现了使用的索引名称
Extra 中的 using index 表明白使用了覆盖索引
锁

Innodb 行锁的实现

行锁是精致度最小的锁，相比于表锁和页面锁发生冲突的可能性最低。根据查询语句的限定行锁由记载锁、间隙锁和临建锁实现例如：
当使用唯一索引进行等值查找，例如 select * from user where id=9 时，innodb 会使用记载锁将 id=9 的数据进行加锁。而当使用 等值大概范围查询时例如 select * from t where id > 1 and id < 6 for update 会及将 id 在 1-6 范围内的数据使用间隙锁进行加锁。select * from t where id > 1 and id 、2 时即使 a 为最左匹配同样不能使用索引，当查询 b=2 c=2 时候未使用最左匹配 不能使用索引。其中使用=和 in 时 abcd 的索引无论为顺序还是乱序，查询优化器会主动优化可识别的形态

团结索引必须按照顺序使用，类似电话簿中的查询，若不知道姓，那查询起来将毫无用处，

当建立一个团结索引 (a,b,c,d) 时，查询条件 a, b, c, d 的顺序不会影响是否使用索引。
https://blog.csdn.net/qq_35275233/article/details/87888809
https://blog.csdn.net/Abysscarry/article/details/80792876
Mysql 日志

binlog 二进制日志 记载数据库所有的更改操作，重要用于数据的备份和规复
redo log 重做日志 保存了事件的持久性 用于数据宕机后的数据规复
undo log 回滚日志 包管了事件的原子性，用于事件的回滚和 MVCC
redo log undo log 是 mysql 中 innodb 引擎独有的
当数据库宕机后，mysql 根据 redolog 进行规复数据库，保持数据的持久性。记载了数据提交后的数据状态
undo log 回滚日志 记载了在事件提交之前的数据状态

• 在事件为提交之前 记载数据到 undo log 中去 当事件回滚时根据 undo log 进行回滚、
  
• 实现 MVCC 通过 Read view +undo log 实现 MVCC
  

手写个 sql 死锁，如果字段非索引会发生死锁吗

begin
update user set age= 1 where id=1;
begin
update user set age =1 where id =2;
此时两个事件均为提交获取到各自的排他锁
事件 1 执行
update user set age = 3 where id = 2;
事件 1 会一直等待释放
update user set age = 2 where id =1;
2 等待 1 释放 进入死锁
如何判断是否使用了索引

利用执行计划 explain 查看查询语句的执行计划 查看其中的 type 字段是否使用了索引
查看表是否有索引 使用 show index from table 的命令
mysql 题目

聚合函数 having group by 的使用场景

聚合函数在 SQL 中用于对数据进行统计和分组计算，而 HAVING 子句通常与 GROUP BY 子句一起使用。HAVING 子句答应对分组后的结果进行筛选，仅返回满足特定条件的分组。
当一个查询语句同时出现了 where、group by、having 和 order by 、join 时，执行顺序如下

查表- 选字段 - 对字段分组- 过滤-筛选-排序

• from join 先执行得到关联的表
  
• WHERE 子句：首先执行 WHERE 子句，提取满足条件的记载。
  
• GROUP BY 子句：然后按照 GROUP BY 子句中指定的列进行分组，一般联合分组聚合函数 COUNT、MAX、SUM 等在 select 中对分组进行过滤。
  
• HAVING 子句：分组后接着使用 HAVING 子句进行过滤保留符合条件的分组。
  
• SELECT 子句：接着执行 SELECT 子句，选择需要表现的列。
  
• ORDER BY 子句：最后根据 ORDER BY 子句中指定的列对结果进行排序。

  having 只能用在 group by 之后
  where 肯定在 group by 之前
  注意若选取的列名和关键字相同 用""包起来表现别名
  

  
  

sql 语句编写顺序

1. SELECT column1, column2
2. FROM table
3. WHERE condition
4. GROUP BY column
5. HAVING condition
6. ORDER BY column
7. LIMIT number;

复制代码

计算时间差

1. TIMESTAMPDIFF(unit, start_date, end_date)  计算时间差
2. unit：HOUR（小时）
3. DAY（天）
4. WEEK（周）
5. MONTH（月）

复制代码

USING 是用于指定连接条件的关键字，通常用于 JOIN 操作中,连接条件是基于列名的相称匹配

1. JOIN table2 USING (column_name);

复制代码

使用 ON 语法时，连接条件是基于一个或多个列之间的逻辑表达式，可以使用比较运算符（如等于、大于等）

1. JOIN table2 ON table1.column_name = table2.column_name;

复制代码

1. year(列名)=时间 提取年份为指定时间的列

复制代码

1. group by 子句后面的列名指定了用于分组的列。所有具有相同值的行会被分为同一组

复制代码

1. avg(col)计算指定列的平均值

复制代码

1. IF(condition, value_if_true, value_if_false)

复制代码

1. ROUND(number, decimals)四舍五入

复制代码

连接字符

1. CONCAT(string1, string2, ...)其中，string1、string2 等是要连接的字符串参数。你可以根据需要提供多个参数。

复制代码

limit

1. limit和OFFSET 使用 OFFSET 子句用於指定返回結果的起始位置

复制代码

count 去重 注意不需要,分割

1. SELECT COUNT(DISTINCT column_name)
2. FROM table_name;

复制代码

case where 表达式
CASE WHEN 表达式可以灵活地在 SELECT 查询、WHERE 条件和 ORDER BY 子句等部分中使用，以满足特定需求。

1. SELECT name, age,
2.     CASE
3.         WHEN age < 18 THEN '未成年'
4.         WHEN age >= 18 AND age < 60 THEN '成年'
5.         ELSE '老年'
6.     END AS age_group
7. FROM users;

复制代码

MyBatis

#{}和${}的区别

#{}：Mybatis 在处理#{}时，是预编译处理，将参数以带引号的占位符的方式添补，能够防止 sql 注入。
${}：是字符串更换，会将 SQL 中的${}更换成变量的实际值。
使用#{}可以有效的防止 SQL 注入，进步系统的安全性。无论内容是什么，都以平凡字符串参数去解析

• 使用${}的场景
  表名作参数时大概使用Order by  group by 等需要列名的解析的场景，必须使用${} 若使用#{}会以字符串的形式更换造成列名包罗引号产生错误
  

SQL 注入 在字符串中注入 SQL 语句，并在执行过程中忽略了字符检查使得数据库执行了恶意的语句并得到意料之外的结果

说说 Mybatis 的一级、二级缓存

• 一级缓存是 MyBatis 的默认缓存，也称为本地缓存。一级缓存是 MyBatis 的默认缓存，也称为本地缓存。
  
• 二级缓存是在多个 SqlSession 之间共享的缓存，它的作用范围更广
  一般使用其他的缓存中间件来进行配置如 redis
  

主键设计

主键作为一条记载的唯一标识，不能有重复 且不为空
如果数据 A 持有某事件的排它锁（Exclusive Lock），那么其他事件对数据 A 加共享锁（Shared Lock）或排它锁都会失败
SQL 语法

SQL 的执行顺序：

• 第一步：执行 FROM 确定具体的数据源
  
• 第二步：WHERE 条件过滤 对数据源源进行过滤清除无关数据
  
• 第三步：GROUP BY 分组 对目的数据进行分组
  
• 第四步：执行 SELECT 投影列 对分组之后的数据进行选择
  
• 第五步：HAVING 条件过滤 对选择后的数据进行过滤
  
• 第六步：执行 ORDER BY 排序 对整体的结果进行排序
  

group by

GROUP BY 是 SQL 中用于分组数据的子句，其焦点作用是将数据按指定字段的值进行分组，每一组数据会作为一个整体进行后续的操作（例如聚合计算）。
GROUP BY 的重要操作是：

• 按字段分组：把表中具有相同字段值的行归为一组。
  
• 应用聚合函数：对 group by 分组后的每组数据中的对应字段进行计算，例如求和 (SUM)、求均匀值 (AVG)、计数 (COUNT)、最大值 (MAX)、最小值 (MIN) 等。
  

分组后，每组数据会返回一条结果。简单理解就是 order by 就是将相同的指定值的记载分为一个组，比如将员工按照部门进行分组；
分组之后每组对应的字段会返回一个数据，而对于未包罗在 group by 中的字段，而若使用了确定的聚合函数就可以指定返回的数据，若没有明确的聚合逻辑，那么 mysql 会随机选择一个对应选择的字段值作为返回；

1. -- 1
2. SELECT id, create_by FROM `t_asn` GROUP BY create_by
3. -- 2
4. SELECT max(id), create_by FROM `t_asn` GROUP BY create_by

复制代码

我们按照 creat_by 进行分组但是 id 没有使用具体的聚合逻辑，实际返回的 id 数据便是 mysql 随机选择的 id 值。
按照 2 表现的查询便是指定了具体的聚合逻辑 max 返回了每组中的最大值

严格来说 在分组查询中，如果一个字段既不在 GROUP BY 子句中，也没有被聚合函数包裹，那么数据库无法确定这个字段在每个分组中应该取哪一行的数据，由于分组后一个组可能包罗多行。而 MySQL 遵循非严格意义上的分组语法 ，作为 mysql 自己的一种特性存在。

• 聚合函数 count
  count(*) 和 count(字段) 的区别
  

having 对分组的进一步过滤

having 的作用是对分组之后的数据进行过滤，当没有使用分组的情况下 having 的意义等同于 where。

1. SELECT sn, COUNT(item_specifications)
2. from t_item GROUP BY sn
3. HAVING MAX(bin_type) > 3

复制代码

过滤顺序晚于 GROUP BY

• HAVING 的过滤是在分组完成后进行的，作用对象是分组后的结果集。
  
• WHERE 则是在分组之进步行过滤，作用对象是原始数据。
  

必须引用分组或聚合的字段

• 在使用 HAVING 时，过滤条件通常需要引用分组字段或聚合字段，否则可能会导致语法错误。
  

order by

order by 一般对最后的结果进行整理排序，分为升序和降序 默认是升序 ASC 降序 DESC
排序过程根据要求的字段顺序进行，ORDER BY 子句中，排序规则按照给定的多个列进行依次排序。如果前面的列无法区分出记载的顺序，就会依次使用背面的列进行排序。
limit 分页查询

返回指定结果的前几行数据
偏移量语法：LIMIT row_count OFFSET offset; 大概 LIMIT row_count , offset;

• offset：从第几条记载开始，索引从 0 开始。
  
• row_count：返回的最大记载数。
  

即从 offset 记载开始返回row_count条记载

LIMIT 查询随着 OFFSET 增大，性能会下降，由于数据库仍然需要扫描和丢弃前面的记载
出现深分页的问题 MP 使用的分页查询便是 limit 关键字实现的

1. -- 返回前三行
2. SELECT create_by, create_time from t_bin ORDER BY create_by DESC, create_time limit 3
4. -- 带偏移量的limit 返回第四条记录后面的四条记录
5. SELECT create_by, create_time from t_bin ORDER BY create_by DESC, create_time limit 3,4

复制代码

子查询


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。