原本使用save时是没有问题了，改成saveOrUpdate 用了一下就报错了。...当saveOrUpdate不使用条件构造器时，会先做根据主键查询，如果查出来的结果为0，那么就执行插入操作，如果查出来的结果不为0，则执行更新操作。 但是一般情况下，主键都不会重复啊！...queryWrapper应用select来设置要查出来的数据。 哈哈，这个还是很重要的！...mybatis-plus在执行时，会先去看看你的对象哪条属性有值，哪条没有。 只会更新有值的属性，所以只会更新4个属性，另外一个属性并不会把他置空。...你想写另外一个值，就可以写进set里。
于是我们赶紧通过 SQL 日志进行问题查找，最后排查出来是因为一张 SQL 的高量查询没有走索引导致。...因为是我自己写的代码，所以知道是哪条 SQL 后我就马上定位到了代码里的具体方法，后来才发现是因为我对 user_fruit_id 字段的判空处理不生效所致。...不得不说，这真是个低级错误，说真的，我对这个原因真是感到嘀笑皆非，再怎么说也工作几年了，怎么还犯一些新手级别的错误呢，这脸打得真是让我相当惭愧。...之前我没有放太大的精力在代码的 Review 上，虽说跟迭代排期的紧凑也有关系，但不管怎么说，Bug 确实是我的疏忽造成的，尤其是像空值这种细小的错误在 Java 里可以说家常便饭。...千里之堤毁于蚁穴，有时一个小 Bug 很容易就引发整个系统的崩盘，这一次的问题也让我更加深刻的认识到了 Review 代码的重要性，不管业务开发的工作量有多麻烦，这一步操作绝对不能忽视。
这让我倒吸了一口凉气，因为我们组做的系统很多都用的是同一个数据库服务器，日用户活跃量有好几十万，如果服务器崩溃了将会使所有的系统服务都不可用。...于是我们赶紧通过 sql 日志进行问题查找，最后排查出来是因为一张 sql 的高量查询没有走索引导致，日志列表显示，这条 sql 语句的扫描行数达到了上百万，基本就是全表扫描的情况，而且半个小时的时间查询了达上万次...因为是我自己写的代码，所以知道是哪条 sql 后我就马上定位到了代码里的具体方法，后来才发现是因为我对 user_fruit_id 字段的判空处理不生效所致。...之前我没有放太大的精力在代码的 review 上，虽说跟迭代排期的紧凑也有关系，但不管怎么说，bug 确实是我的疏忽造成的，尤其是像空值这种细小的错误在 Java 里可以说家常便饭。...知道了 bug 的原因，改完代码当天就重新发布了，后来，二哥告诉我说，为了以后让组里的其他人对此次问题有所警戒，让我写一篇问题记录总结一下，我想了一下，这不是我的强项啊，但怎么说也确实是自己的问题，还是老老实实的写一下记录好了
原本使用save时是没有问题了，改成saveOrUpdate 用了一下就报错了。...，就是这个是根据主键做操作的，但是我主键本来就是自动递增肯定不会有问题的，接下来就是想个办法，让他根据指定字段做操作，好像是有提供了一个口子。...当saveOrUpdate不使用条件构造器时，会先做根据主键查询，如果查出来的结果为0，那么就执行插入操作，如果查出来的结果不为0，则执行更新操作。 但是一般情况下，主键都不会重复啊！...它与queryWrapper的区别就是：updateWrapper用set来设置修改的数据；queryWrapper应用select来设置要查出来的数据。...mybatis-plus在执行时，会先去看看你的对象哪条属性有值，哪条没有。 只会更新有值的属性，所以只会更新4个属性，另外一个属性并不会把他置空。
接着我们来思考一个问题 一个系统只会和MySQL服务器建立一个连接吗？...所以，为了解决TCP无限创建与TCP频繁创建销毁带来的资源耗尽、性能下降问题。 MySQL服务器里有专门的TCP连接池限制接数，采用长连接模式复用TCP连接，来解决上述问题。...小贴士：虽然查询缓存有时可以提升系统性能，但也不得不因维护这块缓存而造成一些开销，从MySQL 5.7.20开始，不推荐使用查询缓存，并在MySQL 8.0中删除。...MySQL服务器要怎么执行呢？ 你需要产出执行计划，交给MySQL服务器执行，所以来到了优化器阶段。 优化器不仅仅只是生成执行计划这么简单，这个过程它会帮你优化SQL语句。...如外连接转换为内连接、表达式简化、子查询转为连接、连接顺序、索引选择等一堆东西，优化的结果就是执行计划。 截止到现在，还没有真正去读写真实的表，仅仅只是产出了一个执行计划。
接着我们来思考一个问题 一个系统只会和MySQL服务器建立一个连接吗？...所以，为了解决TCP无限创建与TCP频繁创建销毁带来的资源耗尽、性能下降问题。 MySQL服务器里有专门的TCP连接池限制接数，采用长连接模式复用TCP连接，来解决上述问题。 ?...小贴士：虽然查询缓存有时可以提升系统性能，但也不得不因维护这块缓存而造成一些开销，从MySQL 5.7.20开始，不推荐使用查询缓存，并在MySQL 8.0中删除。...MySQL服务器要怎么执行呢？ 你需要产出执行计划，交给MySQL服务器执行，所以来到了优化器阶段。 ? 优化器不仅仅只是生成执行计划这么简单，这个过程它会帮你优化SQL语句。...如外连接转换为内连接、表达式简化、子查询转为连接、连接顺序、索引选择等一堆东西，优化的结果就是执行计划。 截止到现在，还没有真正去读写真实的表，仅仅只是产出了一个执行计划。
users表数据，此时该SQL突然会查出很多数据，可能几千、几万、几十万，所以执行此类SQL前，都会先执行count！...，比如判断： 若结果在1k条内，就一下子读出来 若超过1k条，可通过Limit语句，每次就从该结果集里查1k条，查1000条就做一次批量的消息Push，再查下一批次的1k条数据 但在千万级数据量的大表下...让users表的每条数据都和物化临时表里的数据进行join，所以针对users表里的每条数据，只能是去全表扫描一遍物化临时表，从物化临时表里确认哪条数据和他匹配，才能筛选出一条结果。...先执行了子查询查出4561条数据，物化成临时表，接着对users主表全表扫描，扫描过程把每条数据都放到物化临时表里做全表扫描，本质就是在join。...所以就是semi join和物化临时表导致的慢，那怎么优化？
使用 MAT 分析 jvm heap 分析代码 小结 ---- 由来 前些日子小组内安排值班，轮流看顾我们的服务，主要做一些报警邮件处理、Bug 排查、运营 issue 处理的事。...好几次值班组的小伙伴们一起吐槽，商量着怎么避过服务保活机制，偷偷停了探测服务而不让人发现（虽然也并不敢）。 前些天我就在周末处理了一次探测服务的锅。 问题 网络问题？...根据这个猜想，群登上服务器，使用请求的 request_id 在近期服务日志中搜索一下，果不其然，就是网络丢包问题导致的接口超时了。 当然这样 leader 是不会满意的，这个结论还得有人接锅才行。...而我们那个大量 I/O 的接口报警次数特别多，估计跟响应太大需要更多内存有关。 给代码 owner 提了 PR，问题圆满解决。...JsonParserCharArray.java:186) 看到这种报错线程栈却没有细想，要知道 TCP 是能保证消息完整性的，况且消息没有接收完也不会把值赋给变量，这种很明显的是内部错误，如果留意后细查是能提前查出问题所在的
Java 内存泄漏排查实战 | 背景 前些日子小组内安排值班，轮流看顾我们的服务，主要做一些报警邮件处理、Bug 排查、运营 issue 处理的事。...好几次值班组的小伙伴们一起吐槽，商量着怎么避过服务保活机制，偷偷停了探测服务而不让人发现（虽然也并不敢）。 前些天我就在周末处理了一次探测服务的锅。 |问题 网络问题？...根据这个猜想，群登上服务器，使用请求的 request_id 在近期服务日志中搜索一下，果不其然，就是网络丢包问题导致的接口超时了。 当然这样 leader 是不会满意的，这个结论还得有人接锅才行。...而我们那个大量 I/O 的接口报警次数特别多，估计跟响应太大需要更多内存有关。 给代码 owner 提了 PR，问题圆满解决。...JsonParserCharArray.java:186) 看到这种报错线程栈却没有细想，要知道 TCP 是能保证消息完整性的，况且消息没有接收完也不会把值赋给变量，这种很明显的是内部错误，如果留意后细查是能提前查出问题所在的
来源：https://zhenbianshu.github.io/2018/12/troubleshooting_java_memory_leak.html | 背景 前些日子小组内安排值班，轮流看顾我们的服务...好几次值班组的小伙伴们一起吐槽，商量着怎么避过服务保活机制，偷偷停了探测服务而不让人发现（虽然也并不敢）。 前些天我就在周末处理了一次探测服务的锅。 |问题 网络问题？...根据这个猜想，群登上服务器，使用请求的 request_id 在近期服务日志中搜索一下，果不其然，就是网络丢包问题导致的接口超时了。 当然这样 leader 是不会满意的，这个结论还得有人接锅才行。...而我们那个大量 I/O 的接口报警次数特别多，估计跟响应太大需要更多内存有关。 给代码 owner 提了 PR，问题圆满解决。...JsonParserCharArray.java:186) 看到这种报错线程栈却没有细想，要知道 TCP 是能保证消息完整性的，况且消息没有接收完也不会把值赋给变量，这种很明显的是内部错误，如果留意后细查是能提前查出问题所在的
由来 ---- 前些日子小组内安排值班，轮流看顾我们的服务，主要做一些报警邮件处理、Bug 排查、运营 issue 处理的事。工作日还好，无论干什么都要上班的，若是轮到周末，那这一天算是毁了。...好几次值班组的小伙伴们一起吐槽，商量着怎么避过服务保活机制，偷偷停了探测服务而不让人发现（虽然也并不敢）。 前些天我就在周末处理了一次探测服务的锅。...根据这个猜想，群登上服务器，使用请求的 request_id 在近期服务日志中搜索一下，果不其然，就是网络丢包问题导致的接口超时了。 当然这样 leader 是不会满意的，这个结论还得有人接锅才行。...而我们那个大量 I/O 的接口报警次数特别多，估计跟响应太大需要更多内存有关。 给代码 owner 提了 PR，问题圆满解决。...JsonParserCharArray.java:186) 看到这种报错线程栈却没有细想，要知道 TCP 是能保证消息完整性的，况且消息没有接收完也不会把值赋给变量，这种很明显的是内部错误，如果留意后细查是能提前查出问题所在的
好几次值班组的小伙伴们一起吐槽，商量着怎么避过服务保活机制，偷偷停了探测服务而不让人发现（虽然也并不敢）。前些天我就在周末处理了一次探测服务的锅。 ?...根据这个猜想，群登上服务器，使用请求的 request_id 在近期服务日志中搜索一下，果不其然，就是网络丢包问题导致的接口超时了。 当然这样 leader 是不会满意的，这个结论还得有人接锅才行。...解决问题 内存泄漏 于是赶快登陆探测服务器，首先是 top free df 三连，结果还真发现了些异常： ? 我们的探测进程 CPU 占用率特别高，达到了 900%。...而我们那个大量 I/O 的接口报警次数特别多，估计跟响应太大需要更多内存有关。 给代码 owner 提了 PR，问题圆满解决。 小结 其实还是要反省一下自己的，一开始报警邮件里还有这样的线程栈： ?...这种很明显的是内部错误，如果留意后细查是能提前查出问题所在的，查问题真是差了哪一环都不行啊。
在批量制图的过程中，我们发现有时服务器会制作生成一些『异常』的图片…怎么能在图片投放前检测出这种图像，提高图片的可用度呢？...correctEnd.equals(endByte)) { console.log("image data error") } 通过以上方式可以首先排查出因为图片文件本身的数据问题导致的图像不可用情况...02 图像渲染 图片渲染错误一般是因为网络波动问题，服务器拉取对应的元素图片失败，导致渲染出来的图片里有黑屏的情况。如下图所示： ? 这种情况可以通过图片中黑色像素值的占比来判断图片是否可用。...++ } } if (blackNum / pixelNum * 100 >= 90){ console.log("image render error") } 通过上面的方式就可以排查出因为网络问题导致元素内容拉取失败渲染出黑屏的问题了...04 总结 以上，我们分别从图像数据，图像渲染，图像内容，从内到外三个角度来检测和提升图像的可用度。 ? 近期热文 ? 基于云原生基础设施的后台架构设计思考 ? 云时代，我们需要怎样的数据库？ ?
问题背景 最近服务器到期等因素，进行了迁移。租了其它的外国厂商，但是由于资费问题，购买了1.5G 内存的服务器（现）。...因为原本用惯了4G内存的服务器（原），现在压缩成这样，似乎不太能支持我的使用，囧！ 现在就来说下blog服务分配的内存情况： 原：4G 内存，分配给blog，1.5G。...OS：CentOS7Web容器：Tomcat 8ORM：Hibernate3数据库：MySQL5 问题解决过程 诊断排查出现内存泄漏对象 ?...因为Hibernate的一级缓存就是在Session层面上，所以 StatefulPersistenceContext跟一级缓存有关系，网上有些资料也有说 StatefulPersistenceContext...所以一旦加载到内存里，自然的需要占用大部分资源了。 找到问题的点在哪了，接下来就得看怎么优化，毕竟在资源急缺的我，需要优化下当前的服务了。 解决问题，优化！优化！
这是我们应该去考虑的问题，为了解决这个问题，今天继续学习多表查询。 一、笛卡尔积与内连接 万万没有想到，学个数据库竟然还能接触到笛卡尔积？...，也就是内连接的意思。...子查询都要写在 () 里，且执行要先于主查询。 ③all的用法 前面的两个方案中都是使用了聚合函数min()来找出最小的年龄是多少。...子查询查出coder_id，主查询再查出程序员信息。 ①In的使用 in就是表示包含子查询查出的数据。 当子查询结果只有一个时，可以用=，也可以用in。...②any的使用 虽然子查询结果有多个，我就是要用=，怎么办？ 就可以用any，any表示任意的意思，也就是=子查询查出的任意一个数据。
获取服务端IP $_SERVER[‘SERVER_ADDR’] 或者 gethostbyname(‘www.baidu.com’); 将IP地址转换成int ip2long($ip); 好处：存储时可以直接存有符号...当处理完数据后 unset 掉，只能释放当前使用的内存，系统分配的内存并不会变小 内存被分划为， “已使用” 和 “空闲”， unset 只会把 “已使用” 变为 “空闲”， 下次内存请求时会先去”空闲”里取...zh/reserved.variables.php） 超全局变量 — 超全局变量是在全部作用域中始终可用的内置变量 $GLOBALS — 引用全局作用域中可用的全部变量 $_SERVER — 服务器和执行环境信息...SELECT CEILING(COUNT(*) / 3) FROM students; //CEILING()向上取整 使用一条SELECT查询查出每个班级的平均分（四舍五入取整）： ceiling()...，四舍五入取整 SELECT class_id,ceiling(AVG(score)) from students GROUP BY class_id; 请使用一条SELECT查询查出每个班级男生和女生的平均分
$_SERVER[‘SERVER_ADDR’] 或者 gethostbyname(‘www.baidu.com’); 将IP地址转换成int ip2long($ip); 好处：存储时可以直接存有符号...当处理完数据后 unset 掉，只能释放当前使用的内存，系统分配的内存并不会变小 内存被分划为， “已使用” 和 “空闲”， unset 只会把 “已使用” 变为 “空闲”， 下次内存请求时会先去"空闲"里取...zh/reserved.variables.php） 超全局变量 — 超全局变量是在全部作用域中始终可用的内置变量 $GLOBALS — 引用全局作用域中可用的全部变量 $_SERVER — 服务器和执行环境信息...SELECT CEILING(COUNT(*) / 3) FROM students; //CEILING()向上取整 使用一条SELECT查询查出每个班级的平均分（四舍五入取整）： ceiling()...，四舍五入取整 SELECT class_id,ceiling(AVG(score)) from students GROUP BY class_id; 请使用一条SELECT查询查出每个班级男生和女生的平均分
1、show profile的作用： 能够查出最近执行的SQL语句的运行状态，包括在运行过程中执行了哪些操作，各占用了多少时间，利用proflie 功能，可以分析一个SQL具体的执行代价是怎么样的，尤其是可以分析它的最大瓶颈在哪里...大部分情况下，profile 的结果我们主要关注两列：Status、Duration，前者表示的是profile 里的状态，后者是该状态的耗时。...（详细参数请看本文第2点的type参数） show profile cpu,block io for query id; id 为 show profiles 查出来的某条记录的Query_ID。...4、作用范围： （1）这个命令只是在本会话内起作用，即无法分析本会话外的语句。...（3）profiling是针对进程(process)而非线程(threads),因此运行在服务器上的其他服务进程可能会影响分析结果.
原因很简单，很多时候，复杂点的缓存的场景，因为缓存有的时候，不简单是数据库中直接取出来的值 商品详情页的系统，修改库存，只是修改了某个表的某些字段，但是要真正把这个影响的最终的库存计算出来，可能还需要从其他表查询一些数据...也许有的场景是这样的，但是对于比较复杂的缓存数据计算的场景，就不是这样了 如果你频繁修改一个缓存涉及的多个表，那么这个缓存会被频繁的更新，频繁的更新缓存 但是问题在于，这个缓存到底会不会被频繁访问到？？...举个例子，一个缓存涉及的表的字段，在1分钟内就修改了20次，或者是100次，那么缓存跟新20次，100次; 但是这个缓存在1分钟内就被读取了1次，有大量的冷数据 28法则，黄金法则，20%的数据，占用了...80%的访问量 实际上，如果你只是删除缓存的话，那么1分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低 每次数据过来，就只是删除缓存，然后修改数据库，如果这个缓存，在1分钟内只是被访问了1次，那么只有那...不管它会不会用到，而是让它到需要被使用的时候再重新计算 mybatis，hibernate，懒加载，思想 查询一个部门，部门带了一个员工的list，没有必要说每次查询部门，都里面的1000个员工的数据也同时查出来啊
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
