oracle 幻影读,索引+事务

这里写目录标题

事务的ACID特性

数据库的事务是什么？

隔离性(Isolation)概念说明

脏读

可重复读

不可重复读：一个事务A，不同时刻读同一数据可能不一样

幻读：事务A,B同时Insert,B先提交，A没有察觉

InnoDB支持的事务隔离级别

MySQL 中执行事务

1.读未提交:不加锁

2.读提交：解决update/inerst引入的脏读,无法做到可重复读

3.可重复读：解决update引入的不可重复读，不能解决Insert引入的幻读

总结：

MySQL 中是如何实现事务隔离的：可重复读

可重复读——多版本——针对一条事务

可重复读——并发写问题：使用行锁解决——两个事务

可重复读——解决幻读：使用间隙锁解决

总结

索引

简单描述MySQL中，索引，主键，唯一索引，联合索引的区别

超键、候选键、主键、外键分别是什么？

什么时候用唯一索引？

存储引擎选择

索引使用场景(重点)

1.什么情况下设置了索引但无法使用？

B树和B+树

使用B树的好处

使用B+树的好处

数据库为什么使用B+树而不是B树

Mysql中索引分为哪两大类？

1.什么是聚簇索引？何时使用聚簇索引与非聚簇索引

2.非聚簇索引一定会回表查询吗？

3.联合索引是什么？为什么需要注意联合索引中的顺序？

4.B+树在满足聚簇索引和索引覆盖的时候不需要回表查询数据，

索引覆盖(直接命中)和回表问题(多查找一/几次)

1.如何优化？一次找到所有数据？组合索引

常用SQL语句

SQL语句主要分为哪几类

SQL 约束有哪几种？

六种关联查询

什么是子查询

子查询的三种情况

like查询会不会使用索引？

动态SQL

事务的ACID特性

原子性(Atomicity) 原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。

一致性(Consistency) 事务必须使数据库从一个一致性状态变换到另外一个一致性状态。

隔离性(Isolation) 事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

持久性(Durability) 持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来的其他操作和数据库故障不应该对其有任何影响。

数据库的事务是什么？

事务是作为一个单元的一组有序的数据库操作。如果组中的所有操作都成功，则认为事务成功，即使只有一个操作失败，事务也不成功。如果所有操作完成，事务则提交，其修改将作用于所有其他数据库进程。如果一个失败，事务回滚，该事务所有操作的影响都将取消。

隔离性(Isolation)概念说明

以下几个概念是事务隔离级别要实际解决的问题，所以需要搞清楚都是什么意思。

脏读

脏读指的是读到了其他事务未提交的数据，未提交意味着这些数据可能会回滚，也就是可能最终不会存到数据库中，也就是不存在的数据。读到了并不一定最终存在的数据，这就是脏读。

可重复读

可重复读指的是在一个事务内，最开始读到的数据和事务结束前的任意时刻读到的同一批数据都是一致的。通常针对数据更新(UPDATE)操作。

不可重复读：一个事务A，不同时刻读同一数据可能不一样

对比可重复读，不可重复读指的是在同一事务内，不同的时刻读到的同一批数据可能是不一样的，可能会受到其他事务的影响，比如其他事务改了这批数据并提交了。通常针对数据更新(UPDATE)操作。

幻读：事务A,B同时Insert,B先提交，A没有察觉

幻读是针对数据插入(INSERT)操作来说的。假设事务A对某些行的内容作了更改，但是还未提交，此时事务B插入了与事务A更改前的记录相同的记录行，并且在事务A提交之前先提交了，而这时，在事务A中查询，会发现好像刚刚的更改对于某些数据未起作用，但其实是事务B刚插入进来的，让用户感觉很魔幻，感觉出现了幻觉，这就叫幻读。

InnoDB支持的事务隔离级别

SQL 标准定义了四种隔离级别，MySQL 全都支持。这四种隔离级别分别是：

读未提交(READ UNCOMMITTED)

读提交 (READ COMMITTED)

可重复读 (REPEATABLE READ)

串行化 (SERIALIZABLE)

从上往下，隔离强度逐渐增强，性能逐渐变差。采用哪种隔离级别要根据系统需求权衡决定，其中，可重复读是 MySQL 的默认级别。

事务隔离其实就是为了解决上面提到的脏读、不可重复读、幻读这几个问题，下面展示了 4 种隔离级别对这三个问题的解决程度。

只有串行化的隔离级别解决了全部这 3 个问题，其他的 3 个隔离级别都有缺陷。

MySQL 中执行事务

事务的执行过程如下，以 begin 或者 start transaction 开始，然后执行一系列操作，最后要执行 commit 操作，事务才算结束。当然，如果进行回滚操作(rollback)，事务也会结束。

需要注意的是，begin 命令并不代表事务的开始，事务开始于 begin 命令之后的第一条语句执行的时候。例如下面示例中，select * from xxx 才是事务的开始，

begin;

select * from xxx;

commit; -- 或者 rollback;

1.读未提交:不加锁

MySQL 事务隔离其实是依靠锁来实现的，加锁自然会带来性能的损失。而读未提交隔离级别是不加锁的，所以它的性能是最好的，没有加锁、解锁带来的性能开销。但有利就有弊，这基本上就相当于裸奔啊，所以它连脏读的问题都没办法解决。

任何事务对数据的修改都会第一时间暴露给其他事务，即使事务还没有提交。

下面来做个简单实验验证一下，首先设置全局隔离级别为读未提交。

set global transaction isolation level read uncommitted;

设置完成后，只对之后新起的 session 才起作用，对已经启动 session 无效。如果用 shell 客户端那就要重新连接 MySQL，如果用 Navicat 那就要创建新的查询窗口。

启动两个事务，分别为事务A和事务B，在事务A中使用 update 语句，修改 age 的值为10，初始是1 ，在执行完 update 语句之后，在事务B中查询 user 表，会看到 age 的值已经是 10 了，这时候事务A还没有提交，而此时事务B有可能拿着已经修改过的 age=10 去进行其他操作了。在事务B进行操作的过程中，很有可能事务A由于某些原因，进行了事务回滚操作，那其实事务B得到的就是脏数据了，拿着脏数据去进行其他的计算，那结果肯定也是有问题的。

顺着时间轴往表示两事务中操作的执行顺序，重点看图中 age 字段的值。

读未提交，其实就是可以读到其他事务未提交的数据，但没有办法保证你读到的数据最终一定是提交后的数据，如果中间发生回滚，那就会出现脏数据问题，读未提交没办法解决脏数据问题。更别提可重复读和幻读了，想都不要想。

2.读提交：解决update/inerst引入的脏读,无法做到可重复读

既然读未提交没办法解决脏数据问题，那么就有了读提交。读提交就是一个事务只能读到其他事务已经提交过的数据，也就是其他事务调用 commit 命令之后的数据。那脏数据问题迎刃而解了。

读提交事务隔离级别是大多数流行数据库的默认事务隔离界别，比如 Oracle，但是不是 MySQL 的默认隔离界别。

我们继续来做一下验证，首先把事务隔离级别改为读提交级别。

set global transaction isolation level read committed;

每个 select 语句都有自己的一份快照，而不是一个事务一份，所以在不同的时刻，查询出来的数据可能是不一致的。

读提交解决了脏读的问题，但是无法做到可重复读，也没办法解决幻读

3.可重复读：解决update引入的不可重复读，不能解决Insert引入的幻读

可重复是对比不可重复而言的，上面说不可重复读是指同一事物不同时刻读到的数据值可能不一致。而可重复读是指，事务不会读到其他事务对已有数据的修改，及时其他事务已提交，也就是说，事务开始时读到的已有数据是什么，在事务提交前的任意时刻，这些数据的值都是一样的。但是，对于其他事务新插入的数据是可以读到的，这也就引发了幻读问题。

同样的，需改全局隔离级别为可重复读级别。

set global transaction isolation level repeatable read;

在这个隔离级别下，启动两个事务，两个事务同时开启。

可重复读做到了，这只是针对已有行的更改操作有效，但是对于新插入的行记录，

就没这么幸运了，幻读就这么产生了。我们看一下这个过程：

事务A开始后，执行 update 操作，将 age = 1 的记录的 name 改为“风筝2号”；

事务B开始后，在事务执行完 update 后，执行 insert 操作，插入记录 age =1，name = 古时的风筝，这和事务A修改的那条记录值相同，然后提交。

事务B提交后，事务A中执行 select，查询 age=1 的数据，这时，会发现多了一行，并且发现还有一条 name = 古时的风筝，age = 1 的记录，这其实就是事务B刚刚插入的，这就是幻读。

要说明的是，当你在 MySQL 中测试幻读的时候，并不会出现上图的结果，幻读并没有发生，MySQL 的可重复读隔离级别其实解决了幻读问题，这会在后面的内容说明

总结：

读提交：

a) 解决Update/insert的脏读

b) 没解决Update/insert的不可重读

可重复读：

a) Update：还是原来那条语句，保证数据不更新 解决Update的不可重读

b) insert：比原来肯定多一条数据；和原来肯定不一样不能解决insert的不可重读：即幻读

MySQL 中是如何实现事务隔离的：可重复读

首先说读未提交，它是性能最好，也可以说它是最野蛮的方式，因为它压根儿就不加锁，所以根本谈不上什么隔离效果，可以理解为没有隔离。

再来说串行化。读的时候加共享锁，也就是其他事务可以并发读，但是不能写。写的时候加排它锁，其他事务不能并发写也不能并发读。

最后说读提交和可重复读。这两种隔离级别是比较复杂的，既要允许一定的并发，又想要兼顾的解决问题

可重复读——多版本——针对一条事务

为了解决不可重复读，或者为了实现可重复读，MySQL 采用了 MVVC (多版本并发控制) 的方式。

我们在数据库表中看到的一行记录可能实际上有多个版本，每个版本的记录除了有数据本身外，还要有一个表示版本的字段，记为 row trx_id，而这个字段就是使其产生的事务的 id，事务 ID 记为 transaction id，它在事务开始的时候向事务系统申请，按时间先后顺序递增。

按照上面这张图理解，一行记录现在有 3 个版本，每一个版本都记录这使其产生的事务 ID，比如事务A的transaction id 是100，那么版本1的row trx_id 就是 100，同理版本2和版本3。

在上面介绍读提交和可重复读的时候都提到了一个词，叫做快照，学名叫做一致性视图，这也是可重复读和不可重复读的关键，可重复读是在事务开始的时候生成一个当前事务全局性的快照，而读提交则是每次执行语句的时候都重新生成一次快照。

对于一个快照来说，它能够读到那些版本数据，要遵循以下规则：

当前事务内的更新，可以读到；原子性

版本未提交，不能读到；类似，读未提交

版本已提交，但是却在快照创建后提交的，不能读到；类似，读提交

版本已提交，且是在快照创建前提交的，可以读到；类似，可重复读

利用上面的规则，再返回去套用到读提交和可重复读的那两张图上就很清晰了。还是要强调，两者主要的区别就是在快照的创建上，可重复读仅在事务开始是创建一次，而读提交每次执行语句的时候都要重新创建一次。

可重复读——并发写问题：使用行锁解决——两个事务

存在这的情况，两个事务，对同一条数据做修改。最后结果应该是哪个事务的结果呢，肯定要是时间靠后的那个对不对。并且更新之前要先读数据，这里所说的读和上面说到的读不一样，更新之前的读叫做“当前读”，总是当前版本的数据，也就是多版本中最新一次提交的那版。

假设事务A执行 update 操作， update 的时候要对所修改的行加行锁，这个行锁会在提交之后才释放。而在事务A提交之前，事务B也想 update 这行数据，于是申请行锁，但是由于已经被事务A占有，事务B是申请不到的，此时，事务B就会一直处于等待状态，直到事务A提交，事务B才能继续执行，如果事务A的时间太长，那么事务B很有可能出现超时异常。如下图所示。

加锁的过程要分有索引和无索引两种情况，比如下面这条语句

update user set age=11 where id = 1

id 是这张表的主键，是有索引的情况，那么 MySQL 直接就在索引数中找到了这行数据，然后干净利落的加上行锁就可以了。

而下面这条语句

update user set age=11 where age=10

表中并没有为 age 字段设置索引，所以， MySQL 无法直接定位到这行数据。那怎么办呢，当然也不是加表锁了。MySQL 会为这张表中所有行加行锁，没错，是所有行。但是呢，在加上行锁后，MySQL 会进行一遍过滤，发现不满足的行就释放锁，最终只留下符合条件的行。虽然最终只为符合条件的行加了锁，但是这一锁一释放的过程对性能也是影响极大的。所以，如果是大表的话，建议合理设计索引，如果真的出现这种情况，那很难保证并发度。

可重复读——解决幻读：使用间隙锁解决

上面介绍可重复读的时候，那张图里标示着出现幻读的地方实际上在 MySQL 中并不会出现，MySQL 已经在可重复读隔离级别下解决了幻读的问题。

前面刚说了并发写问题的解决方式就是行锁，而解决幻读用的也是锁，叫做间隙锁，MySQL 把行锁和间隙锁合并在一起，解决了并发写和幻读的问题，这个锁叫做 Next-Key锁。

假设现在表中有两条记录，并且 age 字段已经添加了索引，两条记录 age 的值分别为 10 和 30。

总结

MySQL 的 InnoDB 引擎才支持事务，其中可重复读是默认的隔离级别。

读未提交和串行化基本上是不需要考虑的隔离级别，前者不加锁限制，后者相当于单线程执行，效率太差。

读提交解决了脏读问题，行锁解决了并发更新的问题。并且 MySQL 在可重复读级别解决了幻读问题，是通过行锁和间隙锁的组合 Next-Key 锁实现的。

读提交：

a) 解决Update/insert的脏读

b) 没解决Update/insert的不可重读

可重复读：

a) Update：还是原来那条语句，保证数据不更新行锁 解决Update的不可重读

b) insert：比原来肯定多一条数据；和原来肯定不一样间隙锁解决insert的不可重读

索引

简单描述MySQL中，索引，主键，唯一索引，联合索引的区别

索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，他们包含着对数据表里所有记录的引用指针。

普通索引(由关键字KEY或INDEX定义的索引)的唯一任务是加快对数据的访问速度

普通索引允许被索引的数据列包含重复的值。如果能确定某个数据列只包含彼此各不相同的值，在为这个数据列创建索引的时候就应该用关键字UNIQUE把它定义为唯一索引。也就是，唯一索引可以保证数据记录的唯一性。

主键是一种特殊的唯一索引，在一张表中只能定义一个主键索引，主键用于唯一标识一条记录，使用关键字PRIMARY KEY来创建

索引可以覆盖多个数据列，如像INDEX(column A ,column B)索引，这就是联合索引

索引可以极大的提高数据的查询速度，但是会降低插入，删除，更新表的速度，因为在执行这些写操作时，还要操作索引文件。

a) 思考：MyISAM和InnoDb的区别

超键、候选键、主键、外键分别是什么？

超键：在关系中能唯一标识元组的属性集称为关系模式的超键。一个属性可以为作为一个超键，多个属性组合在一起也可以作为一个超键。超键包含候选键和主键。

候选键：是最小超键，即没有冗余元素的超键。

主键：数据库表中对储存数据对象予以唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键，且主键的取值不能缺失，即不能为空值(Null)。

外键：在一个表中存在的另一个表的主键称此表的外键。

什么时候用唯一索引？

除非要保证唯一的需要，否则不用去设置。

有一个弊端：修改的时候，没办法缓存：需要保证唯一，需要进行数据查询。

存储引擎选择

如果没有特别的需求，使用默认的Innodb即可。

MyISAM：以读写插入为主的应用程序，比如博客系统、新闻门户网站。

a) 不支持事务，但是每次查找都是原子性的；

b) 支持表级锁，即每次操作是对整个表加锁；存储表的总行数

c) 一个MyISAM表有三个文件：索引文件、表结构文件、数据文件；

d) 采用非聚集索引，索引文件的数据域存储指向数据文件的指针。辅索引与主索引基本一致，但是辅索引不用保证唯一性

Innodb：更新(删除)操作频率也高，或者要保证数据的完整性；并发量高，支持事务和外键。比如OA自动化办公系统。

a) 支持ACID的事务，支持事务的四种隔离级别

b) 支持行级锁及外键约束：因此可以支持写并发

c) 不存储总行数

d) 主键索引采用聚集索引(索引的数据域存储数据文件本身)，

e) 辅索引的数据域存储主键的值；因此从辅索引查找数据，需要先通过辅索引找到主键值，再访问辅索引；

i. 最好使用自增主键，防止插入数据，为维持B+树结构，文件的大调整。

索引使用场景(重点)

1.什么情况下设置了索引但无法使用？

以“%”开头的LIKE语句，模糊匹配

OR语句前后没有同时使用索引

B树和B+树

使用B树的好处

B树可以在内部节点同时存储键和值，因此，把频繁访问的数据放在靠近根节点的地方将会大大提高热点数据的查询效率。这种特性使得B树在特定数据重复多次查询的场景中更加高效。

使用B+树的好处

由于B+树的内部节点只存放键，不存放值，因此，一次读取，可以在内存页中获取更多的键，有利于更快地缩小查找范围。 B+树的叶节点由一条链相连，因此，当需要进行一次全数据遍历的时候，B+树只需要使用O(logN)时间找到最小的一个节点，然后通过链进行O(N)的顺序遍历即可。而B树则需要对树的每一层进行遍历，这会需要更多的内存置换次数，因此也就需要花费更多的时间

B+树：结点只保存关键字(不保存存储地址),有限的磁盘块(大小1Kb)，能保存更多的关键字。读磁盘次数更少，查找更快

数据库为什么使用B+树而不是B树

B树只适合随机检索，而B+树同时支持随机检索和顺序检索

B+树空间利用率更高，可减少I/O次数，磁盘读写代价更低。

a) 结点只保存关键字(不保存存储地址),有限的磁盘块(大小1Kb)，能保存更多的关键字。读磁盘次数更少，查找更快

B+树的查询效率更加稳定。

a) B树搜索有可能会在非叶子结点结束，越靠近根节点的记录查找时间越短，只要找到关键字即可确定记录的存在，其性能等价于在关键字全集内做一次二分查找。而在B+树中，顺序检索比较明显，随机检索时，任何关键字的查找都必须走一条从根节点到叶节点的路，所有关键字的查找路径长度相同，导致每一个关键字的查询效率相当。

增删文件(节点)时，效率更高。因为B+树的叶子节点包含所有关键字，并以有序的链表结构存储，这样可很好提高增删效率

Mysql中索引分为哪两大类？

聚集索引/主键索引

除聚集索引外，的所有索引都称为二级索引

1.什么是聚簇索引？何时使用聚簇索引与非聚簇索引

聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据

非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，myisam通过key_buffer把索引先缓存到内存中，当需要访问数据时(通过索引访问数据)，在内存中直接搜索索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因

澄清一个概念：innodb中，在聚簇索引之上创建的索引称之为辅助索引，辅助索引访问数据总是需要二次查找，非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引，辅助索引叶子节点存储的不再是行的物理位置，而是主键值

何时使用聚簇索引与非聚簇索引

2.非聚簇索引一定会回表查询吗？

不一定，这涉及到查询语句所要求的字段是否全部命中了索引，如果全部命中了索引，那么就不必再进行回表查询。

a) 举个简单的例子，假设我们在员工表的年龄上建立了索引，那么当进行select age from employee where age < 20的查询时，在索引的叶子节点上，已经包含了age信息，不会再次进行回表查询。

3.联合索引是什么？为什么需要注意联合索引中的顺序？

MySQL可以使用多个字段同时建立一个索引，叫做联合索引。在联合索引中，如果想要命中索引，需要按照建立索引时的字段顺序挨个使用，否则无法命中索引。

具体原因为:

a) MySQL使用索引时需要索引有序，假设现在建立了"name，age，school"的联合索引，那么索引的排序为: 先按照name排序，如果name相同，则按照age排序，如果age的值也相等，则按照school进行排序。省-市-区

b) 当进行查询时，此时索引仅仅按照name严格有序，因此必须首先使用name字段进行等值查询，之后对于匹配到的列而言，其按照age字段严格有序，此时可以使用age字段用做索引查找，以此类推。因此在建立联合索引的时候应该注意索引列的顺序，一般情况下，将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。

4.B+树在满足聚簇索引和索引覆盖的时候不需要回表查询数据，

在B+树的索引中，叶子节点可能存储了当前的key值，也可能存储了当前的key值以及整行的数据，这就是聚簇索引和非聚簇索引。 在InnoDB中，只有主键索引是聚簇索引，如果没有主键，则挑选一个唯一键建立聚簇索引。如果没有唯一键，则隐式的生成一个键来建立聚簇索引。

当查询使用聚簇索引时，在对应的叶子节点，可以获取到整行数据，因此不用再次进行回表查询。

索引覆盖(直接命中)和回表问题(多查找一/几次)

1.如何优化？一次找到所有数据？组合索引

常用SQL语句

SQL语句主要分为哪几类

数据定义语言DDL(Data Ddefinition Language)CREATE，DROP，ALTER

主要为以上操作 即对逻辑结构等有操作的，其中包括表结构，视图和索引。

数据查询语言DQL(Data Query Language)SELECT

这个较为好理解 即查询操作，以select关键字。各种简单查询，连接查询等 都属于DQL。

数据操纵语言DML(Data Manipulation Language)INSERT，UPDATE，DELETE

主要为以上操作 即对数据进行操作的，对应上面所说的查询操作 DQL与DML共同构建了多数初级程序员常用的增删改查操作。而查询是较为特殊的一种 被划分到DQL中。

数据控制功能DCL(Data Control Language)GRANT，REVOKE，COMMIT，ROLLBACK

主要为以上操作 即对数据库安全性完整性等有操作的，可以简单的理解为权限控制等。

SQL 约束有哪几种？

六种关联查询

交叉连接(CROSS JOIN):

a) 笛卡尔积，指不使用任何条件，直接将一个表的所有记录和另一个表中的所有记录匹配

内连接(INNER JOIN)：

a) 指有条件的交叉连接，根据某个条件筛选出符合条件的记录，不符合条件的记录不会出现在结果集中，即内连接之链接匹配的行。

外连接(LEFT JOIN/RIGHT JOIN)

a) 左外连接：LEFT OUTER JOIN, 以左表为主，先查询出左表，按照ON后的关联条件匹配右表，没有匹配到的用NULL填充，可以简写成LEFT JOIN

b) 右外连接：RIGHT OUTER JOIN, 以右表为主，先查询出右表，按照ON后的关联条件匹配左表，没有匹配到的用NULL填充，可以简写成RIGHT JOIN

联合查询(UNION与UNION ALL)

全连接(FULL JOIN)

交叉连接(CROSS JOIN)

什么是子查询

条件：一条SQL语句的查询结果做为另一条查询语句的条件或查询结果

嵌套：多条SQL语句嵌套使用，内部的SQL查询语句称为子查询。

子查询的三种情况

子查询是单行单列的情况：结果集是一个值，父查询使用：=、 等运算符

查询工资最高的员工是谁？

a)select * from employee where salary=(select max(salary) from employee);

子查询是多行单列的情况：结果集类似于一个数组，父查询使用：in 运算符

查询工资最高的员工是谁？

a)select * from employee in salary=(select max(salary) from employee);

子查询是多行多列的情况：结果集类似于一张虚拟表，不能用于where条件，用于select子句中做为子表

a) 1) 查询出2011年以后入职的员工信息

b) 2) 查询所有的部门信息，与上面的虚拟表中的信息比对，找出所有部门ID相等的员工。

select * from dept d, (select * from employee where join_date > '2011-1-1') e where e.dept_id = d.id;

c) 使用表连接：

select d.*, e.* from dept d

inner join employee e

on d.id = e.dept_id

where e.join_date > '2011-1-1'

like查询会不会使用索引？

关键思路：本质是范围查找。索引原理为查找树，需要排序，如何确定一个key的顺序？

排序原理：% 在前面，无法分析，不能走索引；无%或者%在后面，可以走索引

Like不常用，但是却不可避免的出现在需求中。替代方式：ES检索引擎

动态SQL