MySQL查询like语句查询

like运算符:对字符串进行模糊查找

语法：

xx  like '要查找的内容'

含义：

实现对字符串的某种特征信息的模糊查找。它其实依赖于以下2个特殊的"符号"

%:它代表任何个数的任何字符

_  它代表一个任何字符

例1   select*from tab_load_data where    f5 like"%汨罗%"

例2     select*from  tab_load_data where name like  "%韩%"

常见例子和含义

name  like   '%罗%'：表示name中“罗这一字的所有数据行

name   like  '罗%':表示name中罗开头的所有数据行比如罗曼罗兰

name like  ''%罗"  表示以罗结尾所有数据行比如c罗 魂斗罗

name like '罗_'以罗开头并只有2个字符所有数据行比如 罗兰

name like '_罗'以罗结尾并只有2个字符所有数据行比如c罗

要找含有%或_怎么办？

xx like '%\%%'   表示xx中含有百分号（%）

例3     select *from   tab_load_data  where  name  like   '%军'

例2    select *from   tab_load_data  where name  like   '韩%'

在写 select 语句的时候，使用 limit, offset 可能就像是我们吃饭喝水一样自然了。

刚开始工作的时候也经常听前辈们教导：使用 limit, offset，当 offset 变大的时候执行效率会越来越低。

相信在前辈们的言传身教，和自己的实战过程中，大家也都知道了为什么会这样。

因为 select 在执行过程中，对于存储引擎返回的记录，经过 server 层的 WHERE 条件筛选之后，符合条件的前offset 条记录，会被直接无情的抛弃，直到符合条件的第 offset + 1 条记录，才开始发送给客户端，发送了 limit 条记录之后，查询结束。

虽然知道了是什么，也知道了为什么，但是我也一直好奇底层是怎么实现的，所以今天我们来扒一扒它的庐山真面目。

先来简单的回顾一下 select 语句中 limit, offset 的语法，MySQL 支持 3 种形式：

在读取数据的过程中，对于符合条件的前offset 条记录，会直接忽略，不发送给客户端，从符合条件的第 offset + 1 条记录开始，发送 limit 条记录给客户端。

所以，server 层实际上需要从存储引擎读取offset + limit 条记录，源码里也是这么实现的，语法解析阶段，在验证了 offset 和 limit 都是大于等于 0 的整数之后，就把 offset + limit 的计算结果保存到一个叫做 select_limit_cnt 的属性里，offset 也会保存到一个叫做 offset_limit_cnt 的属性里。

来到发送数据阶段，此时的记录已经通过了 WHERE 条件的筛选，接下来就是判断这条记录是不是要发送给客户端。

第 1 步

因为 offset 已经保存到offset_limit_cnt 中了，先来判断 offset_limit_cnt 是否大于 0，如果大于 0，这条记录就会被抛弃了，不发送给客户端；如果等于 0，记录就具备了发送给客户端的资格了，然后接着进入 第 2 步 。

第 2 步

来到这一步，记录就具备了发送给客户端的资格了，至于要不要发，就看客户端想不想要它了，而客户端想不想要它，取决于select_limit_cnt 。

所以，在这一步要判断 已发送记录数量 （send_records）和 需要发送记的录数量 （select_limit_cnt）之间的关系，如果已发送记录数量 大于等于 需要发送的记录数量，则结束查询，否则就接着进入第 3 步。

第 3 步

在这里，记录愉快的等待着被发送给客户端。

既然在offset 变大之后，使用 limit, offset 效率越来越低，那应该怎么办呢？对于实战经验丰富的小伙伴来说，这是相当简单了，但是以防万一刚看到本文的小伙伴是刚刚开始用 SQL 写 Bug，所以还是要大概的写一下的。

以一个 SQL 为例：

为了取到 10 条记录，要先找到 8888 条记录，然后取到需要的 10 条，前面 8888 条记录都白找了，太浪费了，可以这样修改一下：

LAST_MAX_ID 是上一次执行 SQL 时读取到的 主键 ID 的最大值，如果是第一次执行语句， LAST_MAX_ID = 0 。

不过这种方案也有个问题，不支持跳着翻页，只支持顺序翻页（就是每次都点 下一页 的这种）。

如果要支持跳着翻页，怎么办？

只用 MySQL 这把锤子显然有点不够用了，还要再找一把锤子（Redis），可以把符合条件的记录的 主键 ID 都读取出来，存入到 Redis 的有序集合（zset）中，用 zset 相应的函数读取到某一页应该展示的数据对应的那些 主键 ID ，然后用这些主键 ID 去 MySQL 中查询对应的数据，从而用两把锤子间接的实现了分页功能。

当然，这个方案也是有适用场景的，比如，这个方案明显就不适用于这些场景：符合条件的记录非常非常多导致存主键 ID 到 Redis 要占用很大的内存、记录更新频繁导致存主键 ID 的缓存经常被清除。如果碰到更复杂的场景，就要结合业务具体情况具体分析了

DROP TABLE IF EXISTS `test_user` CREATE TABLE `test_user`  (   `id` int(11) NOT NULL,   `name` varchar(30) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,   `hobby` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,   PRIMARY KEY (`id`) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic INSERT INTO `test_user` VALUES (1, 'beibei', 'feifei,guanguan,xiangxiang') INSERT INTO `test_user`(`id`, `name`, `hobby`) VALUES (2, 'feifei', 'call') 表结构如下:（注意两个字符串之间的分割是英文逗号）参数一：表示要查询的字符串。 参数二：表示在表中的哪个字段中查询，填字段名。 例如：FIND_IN_SET("feifei",hobby) 执行结果如下：执行语句如下： SELECT * FROM test_user WHERE hobby like '%guanguan%' 执行结果如下：

---