Heck's Blog

什么是实时主备？
  实时主备由一个主库以及一个或者多个配置了实时（Realtime）归档的备库组成，其主要目的是保障数据库可用性，提高数据安全性。实时主备系统中，主库提供完整的数据库功能，备库提供只读服务。主库修改数据产生的Redo日志，通过实时归档机制，在写入联机Redo日志文件之前发送到备库，实时备库通过重演Redo日志与主库保持数据同步。当主库出现故障时，备库在将所有Redo日志重演结束后，就可以切换为主库对外提供数据库服务
1、环境准备
  服务器 主库IP:192.168.90.41   dm8数据库 实例名 ：RAC1 端口号：5236
  服务器 备库IP:192.168.90.42   dm8数据库 实例名 ：RAC2 端口号：5236
  # 数据库启动服务命令路径/dm8/bin，实例配置文件路径/dm8/data/DAMENG/
  
2、主备库分别初始化实例（按客户要求）
  ./dminit path=/dm8/data page_size=32 instance_name=RAC1
  ./dminit path=/dm8/data page_size=32 instance_name=RAC2

3 备份还原
  # 如果是初始搭建环境，可以通过对主库脱机备份、对备库脱机还原的方式来准备数据， 如果主库已经处于运行状态，则可以对主库进行联机备份、对备库脱机还原的方式来准备数据。

使用Navicat连接SQLserver时，具体报错信息如下：

Installation of this product failed because it is not
supported on this operating system. For information on supported configurations,
see the product documentation.


解决方法：
这个要安装一个叫做sqlncli_x64.msi的东西，手动安装，它在你的Navicat的安装目录下面，比如我的在：

D:\Program Files\PremiumSoft\Navicat Premium



如果你的电脑是64位的，就运行安装那个64位的（我电脑是64位，就只标记出了64位的），如果是32 的就运行那个sqlncli.msi。

然后再进行Sqlserver的链接就不再提示安装出错了。

对于当前数据库的监控方式有很多，分为数据库自带、商用、开源三大类，每一种都有各自的特色；而对于 mysql 数据库由于其有很高的社区活跃度，监控方式更是多种多样，不管哪种监控方式最核心的就是监控数据，获取得到全面的监控数据后就是灵活的展示部分。那我们今天就介绍一下完全采用 mysql 自有方式采集获取监控数据，在单体下达到最快速、方便、损耗最小。本次文章完全使用 mysql 自带的 show 命令实现获取，从 connects、buffercache、lock、SQL、statement、Database throughputs、serverconfig7 大方面全面获取监控数据。

1 连接数（Connects）

• 最大使用连接数：show status like ‘Max_used_connections’

• 当前打开的连接数：show status like ‘Threads_connected’

2 缓存（bufferCache）

• 未从缓冲池读取的次数：show status like ‘Innodb_buffer_pool_reads’

• 从缓冲池读取的次数：show status like ‘Innodb_buffer_pool_read_requests’

• 缓冲池的总页数：show status like ‘Innodb_buffer_pool_pages_total’

• 缓冲池空闲的页数：show status like ‘Innodb_buffer_pool_pages_free’

• 缓存命中率计算：（1-Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests）*100%

• 缓存池使用率为：((Innodb_buffer_pool_pages_total-Innodb_buffer_pool_pages_free）/Innodb_buffer_pool_pages_total）*100%

3 锁（lock）

• 锁等待个数：show status like ‘Innodb_row_lock_waits’

• 平均每次锁等待时间：show status like ‘Innodb_row_lock_time_avg’

• 查看是否存在表锁：show open TABLES where in_use>0；有数据代表存在锁表，空为无表锁

备注：锁等待统计得数量为累加数据，每次获取得时候可以跟之前得数据进行相减，得到当前统计得数据

4 SQL

• 查看 mysql 开关是否打开：show variables like ‘slow_query_log’，ON 为开启状态，如果为 OFF，set global slow_query_log=1 进行开启

• 查看 mysql 阈值：show variables like ‘long_query_time’，根据页面传递阈值参数，修改阈值 set global long_query_time=0.1

• 查看 mysql 慢 sql 目录：show variables like ‘slow_query_log_file’

• 格式化慢 sql 日志：mysqldumpslow -s at -t 10 /export/data/mysql/log/slow.log
  注：此语句通过 jdbc 执行不了，属于命令行执行。
  意思为：显示出耗时最长的 10 个 SQL 语句执行信息，10 可以修改为 TOP 个数。显示的信息为：执行次数、平均执行时间、SQL 语句

备注：当 mysqldumpslow 命令执行失败时，将慢日志同步到本地进行格式化处理。

5 statement

• insert 数量：show status like ‘Com_insert’

• delete 数量：show status like ‘Com_delete’

• update 数量：show status like ‘Com_update’

• select 数量：show status like ‘Com_select’

6 吞吐（Database throughputs）

• 发送吞吐量：show status like ‘Bytes_sent’

• 接收吞吐量：show status like ‘Bytes_received’

• 总吞吐量：Bytes_sent+Bytes_received

7 数据库参数（serverconfig）

show variables

8 慢 SQL

慢 SQL 指的是 MySQL 慢查询，具体指运行时间超过 long_query_time 值的 SQL。
我们常听 MySQL 中有二进制日志 binlog、中继日志 relaylog、重做回滚日志 redolog、undolog 等。针对慢查询，还有一种慢查询日志 slowlog，用来记录在 MySQL 中响应时间超过阀值的语句。慢 SQL 对实际生产业务影响是致命的，所以测试人员在性能测试过程中，对数据库 SQL 语句执行情况实施监控，给开发提供准确的性能优化意见显得尤为重要。那怎么使用 Mysql 数据库提供的慢查询日志来监控 SQL 语句执行情况，找到消耗较高的 SQL 语句，以下详细说明一下慢查询日志的使用步骤：

• 确保打开慢 SQL 开关 slow_query_log

• 设置慢 SQL 域值 long_query_time
  这个 long_query_time 是用来定义慢于多少秒的才算 “慢查询”，注意单位是秒，我通过执行 sql 指令 set long_query_time=1 来设置了 long_query_time 的值为 1, 也就是执行时间超过 1 秒的都算慢查询。

• 查看慢 SQL 日志路径

• 通过慢 sql 分析工具 mysqldumpslow 格式化分析慢 SQL 日志
  mysqldumpslow 慢查询分析工具，是 mysql 安装后自带的，可以通过./mysqldumpslow —help 查看使用参数说明

常见用法：

1. 取出使用最多的 10 条慢查询
   ./mysqldumpslow -s c -t 10 /export/data/mysql/log/slow.log

2. 取出查询时间最慢的 3 条慢查询
   ./mysqldumpslow -s t -t 3 /export/data/mysql/log/slow.log

注意：使用 mysqldumpslow 的分析结果不会显示具体完整的 sql 语句，只会显示 sql 的组成结构；
假如: SELECT FROM sms_send WHERE service_id=10 GROUP BY content LIMIT 0, 1000;
mysqldumpslow 命令执行后显示：
Count: 2 Time=1.5s (3s) Lock=0.00s (0s) Rows=1000.0 (2000), vgos_dba[vgos_dba]@[10.130.229.196]SELECT FROM sms_send WHERE service_id=N GROUP BY content LIMIT N, Nmysqldumpslow 的分析结果详解：

• Count：表示该类型的语句执行次数，上图中表示 select 语句执行了 2 次。

• Time：表示该类型的语句执行的平均时间（总计时间）

• Lock：锁时间 0s。

• Rows：单次返回的结果数是 1000 条记录，2 次总共返回 2000 条记录。

通过这个工具就可以查询出来哪些 sql 语句是慢 SQL，从而反馈研发进行优化，比如加索引，该应用的实现方式等。常见慢 SQL 排查

1. 不使用子查询
   SELECT FROM t1 WHERE id (SELECT id FROM t2 WHERE name=’hechunyang’);
   子查询在 MySQL5.5 版本里，内部执行计划器是这样执行的：先查外表再匹配内表，而不是先查内表 t2，当外表的数据很大时，查询速度会非常慢。
   在 MariaDB10/MySQL5.6 版本里，采用 join 关联方式对其进行了优化，这条 SQL 会自动转换为 SELECT t1. FROM t1 JOIN t2 ON t1.id = t2.id;
   但请注意的是：优化只针对 SELECT 有效，对 UPDATE/DELETE 子 查询无效， 生产环境尽量应避免使用子查询。

2. 避免函数索引
   SELECT FROM t WHERE YEAR(d) >= 2016;
   由于 MySQL 不像 Oracle 那样⽀持函数索引，即使 d 字段有索引，也会直接全表扫描。
   应改为 > SELECT FROM t WHERE d >= ‘2016-01-01’;

3. 用 IN 来替换 OR 低效查询
   慢 SELECT FROM t WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30;
   高效查询 > SELECT FROM t WHERE LOC_IN IN (10,20,30);

4. LIKE 双百分号无法使用到索引
   SELECT FROM t WHERE name LIKE ‘%de%’;
   使用 SELECT FROM t WHERE name LIKE ‘de%’;

5. 分组统计可以禁止排序
   SELECT goods_id,count() FROM t GROUP BY goods_id;
   默认情况下，MySQL 对所有 GROUP BY col1，col2… 的字段进⾏排序。如果查询包括 GROUP BY，想要避免排序结果的消耗，则可以指定 ORDER BY NULL 禁止排序。
   使用 SELECT goods_id,count () FROM t GROUP BY goods_id ORDER BY NULL;

6. 禁止不必要的 ORDER BY 排序
   SELECT count(1) FROM user u LEFT JOIN user_info i ON u.id = i.user_id WHERE 1 = 1 ORDER BY u.create_time DESC;
   使用 SELECT count (1) FROM user u LEFT JOIN user_info i ON u.id = i.user_id;

9 总结

• 任何东西不应过重关注其外表，要注重内在的东西，往往绚丽的外表下会有对应的负担和损耗。

• mysql 数据库的监控支持通过 SQL 方式从 performance_schema 库中访问对应的表数据，前提是初始化此库并开启监控数据写入。

• 对于监控而言，不在于手段的多样性，而需要明白监控的本质，以及需要的监控项内容，找到符合自身项目特色的监控方式。

• 在选择监控工具对 mysql 监控时，需要关注监控工具本身对于数据库服务器的消耗，不要影响到其自身的使用。

问题产生的原因：
由于我远程的Oracle是 11g的，但是Navicat本身的Oracle oci.dll文件是10g的，数据库与链接库的版本不一致，所以会报错。

打开navicat的安装目录，查看有没有以下文件：

解决方案：
1、我们去Oracle官网下载对应的Instant Client Package -Version 11.2.0.4.0 - Basic的文件即可

下载地址：Instant Client for Microsoft Windows (x64) 64-bit
或者自行网上搜索下载
下载好之后，解压到navicat安装目录下

2、启动navicat客户端 找到【工具】->【选项】->【环境】
将OCI环境更改为11_2下的oci.dll即可，重启之后即可生效！

需求分析

1、将excel数据导入数据库中；
2、利用uuid生成的32随机数作主键；
3、利用CURRENT_TIMESTAMP()生成时间；

具体操作

1、根据需要创建表结构
2、将excel数据导入刚创建的表中
注意： 为了能够将excel中的数据导入数据库中，创建数据库表时，暂时将主键去掉，只保留主键字段。
3、在id中生成uuid

UPDATE 表名 SET 列名= UUID();

注意：生成id时，不要直接将uuid()产生的序列中的’’-“通过Replace方法去掉，不然生成的id的将全部相同。
4、将生成的id中的”-"替换掉

UPDATE 表名 SET 列名 = (SELECT REPLACE(对应列名,'-',''));

5、生成时间

UPDATE 表名 SET 列名1 = CURRENT_TIMESTAMP();

mysql分区后每个分区成了独立的文件，虽然从逻辑上还是一张表其实已经分成了多张独立的表，从“information_schema.INNODB_SYS_TABLES”系统表可以看到每个分区都存在独立的TABLE_ID,由于Innodb数据和索引都是保存在".ibd"文件当中（从INNODB_SYS_INDEXES系统表中也可以得到每个索引都是对应各自的分区(primary key和unique也不例外）），所以分区表的索引也是随着各个分区单独存储。

在INNODB_SYS_INDEXES系统表中type代表索引的类型;

0:一般的索引,

1:(GEN_CLUST_INDEX)不存在主键索引的表,会自动生成一个6个字节的标示值，

2:unique索引,

3:primary索引;

所以当我们在分区表中创建索引时其实也是在每个分区中创建索引，每个分区维护各自的索引（其实也就是local index）；对于一般的索引(非主键或者唯一)没什么问题由于索引树中只保留了索引key和主键key(如果存在主键则是主键的key否则就是系统自动生成的6个的key)不受分区的影响；但是如果表中存在主键就不一样了，虽然在每个分区文件中都存在主键索引但是主键索引需要保证全局的唯一性就是所有分区中的主键的值都必须唯一（唯一键也是一样的道理），所以在创建分区时如果表中存在主键或者唯一键那么分区列必须包含主键或者唯一键的部分或者全部列（全部列还好理解，部分列也可以个人猜测是为了各个分区和主键建立关系），由于需要保证全局性又要保证插入数据更新数据到具体的分区所以就需要将分区和主键建立关系,由于通过一般的索引进行查找其它非索引字段需要通过主键如果主键不能保证全局唯一性的话那么就需要去每个分区查找了，这样性能可想而知。

To enforce the uniqueness we only allow mapping of each unique/primary key value to one partition.If we removed this limitation it would mean that for every insert/update we need to check in every partition to verify that it is unique. Also PK-only lookups would need to look into every partition.

索引方式：
性能依次降低
1.主键分区

主键分区即字段是主键同时也是分区字段，性能最好

2. 部分主键+分区索引

使用组合主键里面的部分字段作为分区字段，同时将分区字段建索引（见下面详细说明）

3.分区索引

没有主键，只有分区字段且分区字段建索引

4.分区+分区字段没有索引

只建了分区，但是分区字段没有建索引

总结

因为每一个表都需要有主键这样可以减少很多锁的问题，由于上面讲过主键需要解决全局唯一性并且在插入和更新时可以不需要去扫描全部分区，造成主键和分区列必须存在关系；所以最好的分区效果是使用主键作为分区字段其次是使用部分主键作为分区字段且创建分区字段的索引，其它分区方式都建议不采取。


MYSQL的分区字段，必须包含在主键字段内
在对表进行分区时，如果分区字段没有包含在主键字段内，如表A的主键为ID,分区字段为createtime ，按时间范围分区，代码如下：

CREATE TABLE T1 (
     id int(8) NOT NULL AUTO_INCREMENT,
     createtime datetime NOT NULL,
      PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8
PARTITION BY RANGE(TO_DAYS (createtime))
(
PARTITION p0 VALUES LESS THAN (TO_DAYS('2010-04-15')),
PARTITION p1 VALUES LESS THAN (TO_DAYS('2010-05-01')),
PARTITION p2 VALUES LESS THAN (TO_DAYS('2010-05-15')),
PARTITION p3 VALUES LESS THAN (TO_DAYS('2010-05-31')),
PARTITION p4 VALUES LESS THAN (TO_DAYS('2010-06-15')),
PARTITION p19 VALUES LESS ThAN  MAXVALUE);
复制代码
错误提示：#1503

MySQL主键的限制，每一个分区表中的公式中的列，必须在主键/unique key 中包括，在MYSQL的官方文档里是这么说明的
18.5.1. Partitioning Keys, Primary Keys, and Unique Keys
This section discusses the relationship of partitioning keys with primary keys and unique keys. The rule governing this relationship can be expressed as follows: All columns used in the partitioning expression for a partitioned table must be part of every unique key that the table may have.

In other words,every unique key on the table must use every columnin the table's partitioning expression. (This also includes the table's primary key, since it is by definition a unique key. This particular case is discussed later in this section.) For example, each of the following table creation statements is invalid:
分区字段必须包含在主键字段内，至于为什么MYSQL会这样考虑，我觉得是这样的：为了确保主键的效率。否则同一主键区的东西一个在Ａ分区，一个在Ｂ分区，显然会比较麻烦。

下面讨论解决办法，毕竟在一张表里，日期做主键的还是不常见。
方法1：
顺应MYSQL的要求，就把分区字段加入到主键中，组成复合主键
CREATE TABLE T1 (
     id int(8) NOT NULL AUTO_INCREMENT,
     createtime datetime NOT NULL,
      PRIMARY KEY (id,createtime)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8
PARTITION BY RANGE(TO_DAYS (createtime))
(
PARTITION p0 VALUES LESS THAN (TO_DAYS('2010-04-15')),
PARTITION p1 VALUES LESS THAN (TO_DAYS('2010-05-01')),
PARTITION p2 VALUES LESS THAN (TO_DAYS('2010-05-15')),
PARTITION p3 VALUES LESS THAN (TO_DAYS('2010-05-31')),
PARTITION p4 VALUES LESS THAN (TO_DAYS('2010-06-15')),
PARTITION p19 VALUES LESS ThAN  MAXVALUE);
测试通过，分区成功。

大家都知道删除分区的语句如下：
ALTER TABLE '表名' DROP PARTITION '分区名' ; 但是这样的话只能一个个分区去删除，而且删除分区同时会把数据也给删除掉了，那么mysql删除表的所有分区如何操作呢？
只要使用ALTER TABLE 表名 REMOVE PARTITIONING 就可以删除所有分区，但数据不会被删除。

查询指定表的分区信息以及每个分区的行数
SELECT PARTITION_NAME,TABLE_ROWS
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_NAME = '表名';

SELECT
  PARTITION_NAME,PARTITION_DESCRIPTION,
FROM_UNIXTIME(PARTITION_DESCRIPTION,'%Y-%m-%d') EXPIRYDATE,TABLE_ROWS
FROM
INFORMATION_SCHEMA.PARTITIONS where TABLE_NAME ='表名';

今天主要介绍下面这几个错误:

ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning

ERROR 1503 (HY000): A UNIQUE INDEX must include all columns in the table's partitioning function

主键必须包括表的分区函数中的所有列，一个惟一的索引必须包括表的分区函数中的所有列，是不是不太好理解意思

其实就是这么个意思：表上的每一个唯一性索引必须用于分区表的表达式上（其中包括主键索引）

下面我来举几个例子：


CREATE TABLE t1 (  
     id INT NOT NULL,  
     aid DATE NOT NULL,  
     bid INT NOT NULL,  
     PRIMARY KEY (id)  
)  
PARTITION BY KEY(bid)  
PARTITIONS 10;
[Err] 1503 - A PRIMARY KEY must include all columns in the table's partitioning function


CREATE TABLE t1 (  
     id INT NOT NULL,  
     aid DATE NOT NULL,  
     bid INT NOT NULL,    
     UNIQUE KEY (id)  
)  
PARTITION BY KEY(bid)  
PARTITIONS 10;
[Err] 1503 - A PRIMARY KEY must include all columns in the table's partitioning function


CREATE TABLE t1 (  
     id INT NOT NULL,  
     aid DATE NOT NULL,  
     bid INT NOT NULL,  
     PRIMARY KEY (id,bid)  
)  
PARTITION BY KEY(bid)  
PARTITIONS 10;
Query OK, 0 rows affected (0.535 sec)

一、所有库在同一节点上
　当业务垂直拆分出很多业务库的时候，如果都部署在同一个源上（同一个机器节点上），那么这种情况是最好办的，直接库名+表名 join就可以。

二、不在一个节点

当不同的库来自不同的节点，那么就没办法直接join查询了，有以下方式和思路：
1.全局表
　　所谓全局表，就是有可能系统中所有模块都可能会依赖到的一些表。比较类似我们理解的“数据字典”。为了避免跨库join查询，我们可以将这类表在其他每个数据库中均保存一份。同时，这类数据通常也很少发生修改（甚至几乎不会），
　　所以也不用太担心“一致性”问 题。

2.字段冗余
　　这是一种典型的反范式设计，在互联网行业中比较常见，通常是为了性能来避免join查询。字段冗余能带来便利，是一种“空间换时间”的体现。但其适用场景也比较有限，比较适合依赖字段较少的情况。

　　最复杂的还是数据一致性问题，这点很难保证，可以借助数据库中的触发器或者在业务代码层面去保证。当然，也需要结合实际业务场景来看一致性的要求。


3.数据同步
　　定时A库中的tab_a表和B库中tbl_b有关联，可以定时将指定的表做同步。当然，同步本来会对数据库带来一定的影响，需要性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库查询。笔者曾经在项目中是通过ETL工具来实施的。


4.第三方插件
　　　　1.cobar
　　　　2.MyCAT
　　　　3.shardding-jdbc

一、前言
MySQL 支持由 RFC 7159 定义的原生JSON 数据类型，该数据类型可以有效访问 JSON（JavaScript Object Notation）中的元素数据。与将JSON 格式的字符串存储为单个字符串类型相比，JSON 数据类型具有以下优势：

自动验证存储在JSON列中的JSON数据格式。无效格式会报错。
优化的存储格式。存储在JSON列中的JSON文档被转换为允许快速读取访问文档元素的内部格式。内部是以二进制格式存储JSON数据。
对JSON文档元素的快速读取访问。当服务器读取JSON文档时，不需要重新解析文本获取该值。通过key或数组索引直接查找子对象或嵌套值，而不需要读取整个JSON文档。
存储JSON文档所需的空间，大致与LONGBLOB或LONGTEXT相同
存储在JSON列中的任何JSON文档的大小都仅限于设置的系统变量max_allowed_packet的值
MySQL 8.0.13之前，JSON列不能有非null的默认值。
在 MySQL 8.0 中，优化器可以对 JSON 列执行部分就地更新，而不是删除旧JSON串并将新串完整地写入列。
MYSQL 8.0，除了提供JSON 数据类型，还有一组 SQL 函数可用于操作 JSON 的值，例如创建JSON对象、增删改查JSON数据中的某个元素。

二、常用JSON函数
首先，创建表列时候，列要设置为JSON类型：

1
CREATE TABLE t1 (content JSON);
插入数据，可以像插入varchar类型的数据一样，把json串添加单引号进行插入：

1
INSERT INTO t1 VALUES('{"key1": "value1", "key2": "value2"}');
当然mysql也提供了创建JSON对象的函数：

1
INSERT INTO t1 VALUES(JSON_OBJECT("key1","value1","key2","value2"));
使用JSON_EXTRACT函数查询JSON类型数据中某个元素的值：


mysql> SELECT  JSON_EXTRACT(content,"$.key1") from t1;

+--------------------------------+
| JSON_EXTRACT(content,"$.key1") |
+--------------------------------+
| "value1"                       |
| "value1"                       |
+--------------------------------+
2 rows in set (0.00 sec)
lamba表达式风格查询：


mysql> SELECT content->"$.key1" from t1;
+-------------------+
| content->"$.key1" |
+-------------------+
| "value1"          |
| "value1"          |
+-------------------+
2 rows in set (0.00 sec)
使用JSON_SET函数更新JSON中某个元素的值，如果不存在则添加：


mysql> update t1 set content=JSON_SET(content,"$.key1",'value111');
Query OK, 2 rows affected (0.00 sec)

Rows matched: 2  Changed: 2  Warnings: 0
更多JSON类型数据操作函数，可以参考：https://dev.mysql.com/doc/refman/8.0/en/json.html

三、MyBatis中使用JSON类型及其操作函数
比如Device表里面有个JSON类型的content字段，其中含有名称为name的元素，我们来修改和查询name元素对应的值。

ExtMapper中定义修改和查询接口：

@Mapper
public interface DeviceDOExtMapper extends com.zlx.user.dal.mapper.DeviceDOMapper {
    //更新JSON串中名称为name的key的值
    int updateName(@Param("name") String name, @Param("query") DeviceQuery query);
    //查询JSON串中名称为name的key的值
    String selectName(DeviceQuery query);
}
ExtMapper.xml中定义查询sql:

<mapper namespace="com.zlx.user.dal.mapper.ext.DeviceDOExtMapper">
    <!--更新JSON串中名称为name的key的值-->
    <update id="updateName" parameterType="map">
        update device
        <set>
            <if test="name != null">
                content = JSON_SET(content, '$.name', #{name,jdbcType=VARCHAR})
            </if>
        </set>
        <if test="_parameter != null">
            <include refid="Update_By_Example_Where_Clause"/>
        </if>
    </update>

    <!--查询JSON串中名称为name的key的值-->
    <select id="selectName" parameterType="com.zlx.user.dal.model.DeviceQuery" resultType="java.lang.String">
        select
        `content`->'$.name'
        from device
        <if test="_parameter != null">
            <include refid="Example_Where_Clause"/>
        </if>
    </select>
</mapper>
总结
虽然我们实践上不建议把所有扩展字段都放到一个大字段里面。但是即使有原因一定到放，那么也建议选择JSON类型，而不是varcahr和Text类型。


参考：
https://dev.mysql.com/doc/refman/8.0/en/json.html