东营免费建网站,幼儿活动设计方案模板,wordpress禁用更新提示,高端网站策划公司一、关于效率和适用范围 尽管官方承诺Json格式字段采用了空间换时间的策略#xff0c;比Text类型来存储Json有大幅度的效率提升。但是Json格式的处理过程仍然效率不及传统关系表#xff0c;所以什么时候用Json格式字段尤为重要。 只有我们确定系统已经能精确定位到某一行比Text类型来存储Json有大幅度的效率提升。但是Json格式的处理过程仍然效率不及传统关系表所以什么时候用Json格式字段尤为重要。 只有我们确定系统已经能精确定位到某一行比如用主键、创建时间范围等这时候我们的数据集合比较小那么我们就可以放心大胆的用Json格式字段进行进一步数据处理而且Json中所存储的信息一定不是检索时必要的筛选信息和统计时需要计算的关键数据不要妄想在百万行Json字段里对某一个Json属性进行搜索、聚合这属于纯粹找虐。 比如说我们读个字典以往要拆成两个表现在一个表就可以解决或者说ERP系统里我们可以把万年不查的子表、孙表都放在一个Json字段里这样用单表即可解决复杂结构化数据存储的问题。 举个每个人都知道具体场景的例子CMS系统有内容页传统方式解决扩展字段大多都用键值对表也就是窄表来解决问题但事实上键值对表的查询非常慢所有的数据都以TEXT的方式存储因为要照顾到富文本自定义字段因此非常难以查询当用户已经点击进入内容页的时候我们已知具体是内容表的哪一行此时直接将JSON数据返回给前端的效率要完全优于遍历键值对表而且还能对Json的某个属性加索引也可以对整个Json串加全文索引这样对某个栏目下的有限内容的同一个字段就很容易进行统计。 再举一个经常遇到的例子业务总是在变化字段总要变需要兼顾灵活性和效率不得不用Json字段来处理数据。 二、实测前的准备工作 建表就不用说了主流建表工具都支持建立Json列。 插入和更新数据也不用说了就当是操作字符串即可只有一个局部更新可能需要用到后面会讲到。 我们这里主要讲查询。 假设我们有这么一个表my_table后面的例子都用它来举例 CREATE TABLE my_table (id bigint NOT NULL AUTO_INCREMENT,code varchar(255) NULL,name varchar(255) NULL,attrs json NULL,create_time datetime NULL,creator bigint NULL,last_modify datetime NULL,modifier bigint NULL,time_stamp datetime NULL,deleted tinyint NULL,PRIMARY KEY (id) );然后我们准备好要测试的数据 INSERT INTO my_table (id, code, name, attrs, create_time, creator, last_modify, modifier, time_stamp, deleted) VALUES (1, menu, 菜单, [{\code\: \menu1\, \name\: \菜单1\}, {\code\: \menu2\, \name\: \菜单2\}], NULL, NULL, NULL, NULL, NULL, NULL); INSERT INTO my_table (id, code, name, attrs, create_time, creator, last_modify, modifier, time_stamp, deleted) VALUES (2, sysConfig, 系统设置, {\sysName\: \某综合管理系统\, \wxAppId\: \wx1234567\}, NULL, NULL, NULL, NULL, NULL, NULL); INSERT INTO my_table (id, code, name, attrs, create_time, creator, last_modify, modifier, time_stamp, deleted) VALUES (3, site, 站点设定, [{\code\: \a.myweb.com\, \extra\: {\owner\: \rantUser1\}, \visited\: 200}, {\code\: \b.myweb.com\, \extra\: {\owner\: \rantUser1\}, \visited\: 300}, {\code\: \www.example.com\, \extra\: {\owner\: \rantUser2\}, \visited\: 157}, {\code\: \b2c.example.com\, \extra\: {\owner\: \rantUser2\}, \visited\: 775}], NULL, NULL, NULL, NULL, NULL, NULL); 都导入之后数据大概是这样子的 各种查询方法 晦涩难懂的官方原版Manual就不给大家重复了直接上干货 Json转表 Json转表是第一个要解决的问题只要变成我们熟悉的表很多传统MySQL的关联表、集合查询之类的操作都能用上了。 SELECT b.* FROM my_table AS a JOIN JSON_TABLE( a.attrs, $[*] COLUMNS (code VARCHAR(20) PATH $.code,name VARCHAR(20) PATH $.name) ) AS b WHERE a.code menu解析直接看图吧 查询结果 取属性 我们很多时候面向对象开发需要用到ORM框架但每次都要当做String来用FastJson、Gson之类的框架来解析实在是太麻烦。例如我们有MyBatis这样的框架直接在SQL语句里把Json的字段都附加上上层所有的应用框架全都可以认岂不是一劳永逸。 SELECT *,attrs-$.sysName sys_name,attrs-$.wxAppId wx_app_id from my_table where codesysConfig查询结果如下 维度抽取 这个是针对数组的echarts之类的框架会需要用到这里不做赘述 select attrs-$[*].code code_list,attrs-$[*].name name_list from my_table where codemenu查询结果 还可以针对多行一起获得维度抽取的结果如果碰到JSON不是数组的它也不会报错只是返回一个null非常人性化 select id,code,name,attrs-$[*].code sub_code from my_table查询结果 聚合操作 这次我们把已经设定的站点都取出来根据所有者的不同把他们网站的访问量都统计出来 SELECTb.owner,sum(b.visited) visited FROM my_table AS a JOIN JSON_TABLE( a.attrs, $[*] COLUMNS (owner VARCHAR(20) PATH $.extra.owner,visited BIGINT PATH $.visited) ) AS b WHEREa.code site GROUP BY owner局部更新 有时候我们并不想把整个Json都更新了只想更新其中一个值比如多人同时更新一个Json时各个内存中完整的Json副本都不一样如果贸然全量更新就会互相覆盖 UPDATE my_table SET attrs JSON_SET(attrs, $.sysName, 某网站管理系统) WHERE codesysConfig;通过上面这个方式就可以局部更新sysName这个key对应的值MySql内部做了优化如果值是相同的影响行数则返回0它并不会无脑覆盖。 总结 至于其他的用法对于应用层面开发来说没什么太大用途主要原因是大批量的Json加工压力还是在前端和后台所以数据库层面只需要关注读取方式、效率以及和ORM框架的兼容性即可。Json字段对于低代码开发、元数据、动态表单之类的应用是很有帮助的特别是对有些动态数据结构的加工来说省了很多精力。