【IT老齐133】牛逼！200毫秒干到10毫秒，利用MySQL JSON特性优化千万级文库表

香草味的橙子:
可以,我们是也有这个问题,不过我们选择了mongodb,当初对mysql的虚拟列不太了解所以当初想mysql的json格式可能存在查询的问题就不再选择范围内了 mongo可以很好的解决json的问题 不过mysql使用这个技术可以解决 运营平台那种多表关联的查询所带来的问题,毕竟mongo跨表是非常不建议的

【回复】回复 @不高兴就跑步去 :MySQL提供现成的功能不用，非要自己造轮子去维护？
【回复】回复 @不高兴就跑步去 :看问题很深呀，不过现实环境啥情况都可能发生，比如提前设计的时候就失误，就需要增加个虚拟列，当然一般有改表的权限也可以做数据迁移同时增加列，多了一种方案。
【回复】是的，今天我们聊完以后也觉得这是一个很好的用例。确实能用反范式解决多表关联问题
wanglve:
提速并不是靠json，还是靠索引啊～你用json创建虚拟列，再在列上创建索引提速，这还不如直接创建数据字段，再加索引呢，而且可读性还好，因为是虚拟列，如果json特别长，每条json的数据解析必然耗费更多资源～而且这种设计过于自由，没有良好文档，很容易引发混乱

【回复】写固定的列，意味着新增加书的类型，还要去修改表结构。
【回复】通过索引快速定位数据，然后再进行数据解析，单条json解析没那么慢
【回复】回复 @祸之穷奇 : 这个貌似也需要增加表结构（在需要查询的情况下需要建立索引，也是需要一步操作的）
优子大神:
优化就是见招拆招，图书信息的特点就是几乎不会改变，不会修改。设置一个json字段，既解决了宽表的字段膨胀，又简单了查询，确实不错。

【回复】回复 @wangyf600 :视频中只支持x_request_id查询json，如果还要支持其他条件，估计又要加一列了。虽然es也可以做到甚至更好，但是也算学会了mysql的一种方式吧
【回复】假如的表里有非常多的种类，这样要生成的虚拟列是不是就太多啦？
airzhangfish_:
老齐的这个方法超赞，前半段知道如何用，后半段虚拟列json属性的操作确实非常干货，学习了

飒飒黎:
凌晨四点起来WC后睡不着，来b站正好推荐给我这个视频，作为一个2.5年经验的新手正好遇到公司在用JSON类型的数据，对于这个虚拟表的索引方式非常受用，可以考虑到时候在某些情况下加入该方案。遇到了宝藏up[打call]

不忘愛:
13:54 省流：解析查询 json 字段，创建 json 虚拟列

【回复】虚拟列：动态同步更新（只读）> 建立索引，这样就能把全表查询改成索引查询了
萌懵eunji:
如果需要根据json字段的属性值进行分组排序，这种方案就不适用了吧

【回复】回复 @Justinwins :基于索引实现与物理列性能基本一致
【回复】回复 @IT老齐 : 为啥？虚拟列上如果有索引，然后针对虚拟列分组排列会有啥性能问题吗
漂流邑人:
小白疑问：创建虚拟列不锁表？那是实时计算的吗？谢谢回复

【回复】是实时运算的，不过建立虚拟列索引，以后会根据值，来构建索引
【回复】回复 @IT老齐 :谢谢， 那索引应该不是实时计算了吧？不然太耗性能 我猜这个索引和其他索引差不多，只是主键+虚拟列值组成的一个树是吧。
【回复】数据的存储是实时运算，但是可以基于索引优化，快速定位到数据以后，再通过实时预算提取这次结果
齐木华佗:
请问下如果我的json数据可能是多组是否支持这么优化 [{"id":1,"name":"张三"},{"id":2,"name":"老齐"}]

【回复】那就给他行专列做一个唯一标识符区分
【回复】我先蹲个位置，等大佬解答
想想你我就心塞:
如果json是个数组怎么添加虚拟列呢[脸红]

【回复】这种底层直接看官网啊，到了这种水平了基本都只会讲个大概，讲详细了要成本的啊喂。较小众的基本都收不回成本。不要老是想白嫖额。
【回复】我先蹲个位置，等大佬解答
loser-hh:
大佬 问一下json_table 提取分组 sum慢 有什么优化办法嘛

挖掘技术的菜鸡:
问题来了，什么时候该用虚拟列，什么时候不该用？非虚拟列现在的存在意义是什么？

比克提尼v:
哎，后端直接把json数据塞进数据库里，被迫用这种办法

【回复】回复 @极简的22 :全干了现在
奔跑的香蕉3号:
之前就在想怎么优化这个json的列, 准备用json放入一些tag类似k8s的lable来查询

专注-高效:
我想问下mysql json数据类型能存储多大的数据，也就是json字符串大小有没有限制？

VAN20221010:
我也支持使用mongodb mysql干mysql专长的事情就得了 不过mysql的野心很大 mysql还支持全文索引了[滑稽][滑稽]