OSCHINA 问答合集[1]:老大竟然说我不会写 SQL ……

发布于 2018/05/08 17:58
阅读 6K+
收藏 32

【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”

开源中国问答区新栏目“OSCHINA 问答合集”上线啦,本期收录了 3-4 月高热度的问题及回复(吐槽),希望能让你有所收获~!

进入问答区:

你可以在技术问答版块畅聊技术
你可以在职业生涯版块寻道解惑
你可以在IT大杂烩版块和大家谈笑风生

我们希望:

这里可以成为一个能让大家有所收获的地方。因此,这里拒绝攻击、拒绝谩骂、拒绝无脑黑。
这里可以沉淀大家各种的技术问题。无论是新手的基础问题,还是高端玩家的资深问题,都是有价值的。
这是一个更纯粹讨论技术的地方,能给程序员提供一片友好交流的清净之地,不懂的可以在这里寻找帮助,懂的可以在这里帮助别人。

总之,

在这里你可以向所有人提问。
反正你的问题可能会没答案。;-)

==========分割线==========

开源中国技术问答

@蓝水晶飞机 老大偏要一条SQL搞定 SELECT 到 业务计算 到 UPDATE,我分十几行SQL来写真的菜鸡么

老大交代一个 SQL 统计任务存储过程要实现,业务过程稍微复杂,大概有10来个步骤。

于是我就采用那种先处理获取所需要的数据存放到表变量的思路,大概是:

INSERT @表变量 SELECT FROM ...

相关的数据都是类似的思路进行处理,最后将要 UPDATE 的数据都准备好在一个内存表里面,最后一个游标循环 UPDATE 到业务表。

老大竟然说我不会写 SQL 。。。

最后他自己写了个,执行要好几秒钟,而我写的,几百毫秒左右几乎感觉不到。

他喵的是我还是他较真了。

楼主是搞 Java 的,都喜欢清晰的逻辑(所以使用了和 Java Collection 类似的套路去写),喜欢讲步骤细化成简单易于理解的一行一行的代码,而就老大写的哪呀那个一坨 SQL 代码多难理解啊!性能也慢这么多(超 3 秒的就一坨屎了)。

额~这是一个过去的话题。

>>>@魔力猫

SQL是面向集合的语言,你们老大的SQL有毛病,你这个路子也有问题。

建议你先尝试分析一下你们老大的存储过程,看看到底是哪里有问题。然后你也可以把自己的东西想想,看那些是可以一条完成而不是一条条。

最后,SQL业务执行除了速度,还有内存空间占用率,读写消耗这些指标。

>>>@BoXuan

过多的依赖SQL,后期优化就只有一条路,不停的SQL优化,直到无路可走。特别是存储过程,跟分库分表这种优化方案都不太合拍,更何况还有缓存之类的优化,存储过程虽然在一定程度上加速了SQL的执行效率,但内部含有一定的业务逻辑,而缓存之间的读写只能依赖业务代码,当然也得视情况而定,有些老资历程序员甚至要求不允许有外键、存储过程。

@烛✟孩 10个sql,dbcp连接池,分给10个线程去执行,为什么效率没有提高呢?

要查10个SQL语句,每句执行的时候都略长,于是决定开多线程来执行。

在navicat premium软件中10个语句开两个查询窗口执行,每个执行5个,时间明显缩短,

为什么在程序中,开多线程执行,时间没有节省呢?

10个线程中,检查过connection的hashCode是不同的,

难道这10个connection在排队呢?

求指点

>>>@石头捡到布

在创建连接池的时候,设置初始连接数,按照你说的,你检查了10个连接的hashcode都不相同,那么初始化连接应该没有问题,假如你一条sql需要5秒,你开始的时候直接查询10个sql,是串行的,所以需要50秒的时间这个没有问题,按照理论那么10个线程每个执行一条sql并发执行,不说5秒之内执行完毕,最起码应该低于50秒,但是由于你的sql性能过低,并发请求导致数据库压力变大或者操作同样的数据导致行锁,甚至可能会出现死锁。

>>>@魔力猫

如果说10个全都是全表,那么除了数据库倒霉消耗增加10倍,没有一毛钱节约。分批返回,还要加上额外的通讯握手交互成本。

先尝试优化SQL吧,搞清楚执行时间长的具体原因再说。特别是如果大量全表,怎么也降不下来的。

>>>@lijegd

这个和连接池没有关系了,相当于你之前是数据库 1个sql并发,现在是10个并发,按你的描述,这些sql耗时较长,那占用资源也很可能较大,你超10个线程,相当于 10个 占用较大资源 的sql并发,数据库压力这时会增大,原来1个sql执行要5s,那么在10个并发的请求,这个sql可能执行要 50s。相对于开线程前后,数据库的资源一定,并发情况下,起到负优化也是正常的。

@BoXuan 二维数组旋转的坐标变换

二维数组旋转的坐标变换,可以绕任意点旋转。

网上资料有一个变换矩阵,但我想要一个坐标转换的公式,数学功底不扎实,特来求教大神。

double radian = (Math.PI / 180) * angle;
double cos = Math.cos(radian);
double sin = Math.sin(radian);
tx、ty为旋转围绕点坐标

double nx = x * cos - y * sin + ((1 - cos) * tx + ty * sin);
double ny = x * sin + y * cos + ((1 - cos) * ty - tx * sin);

按照网上资料组合的,但只能计算一维、二维长度相同、且只能绕(0, 0)点或中心点旋转0度或90度的倍数。其它情况nx、ny都有负数的情形,理论上是不应该出现负数的。

https://blog.csdn.net/csxiaoshui/article/details/65446125 我是按照这篇博客中的改过来的,请问我的公式有什么问题呢? 

>>>@乌龟壳

那个公式没看懂,刚自己推了下给你参考下

中点为cx,cy,旋转弧度为radian

dx = x-cx
dy = y-cy
r = sqrt(dx*dx+dy*dy)
radian1 = atan(dy/dx) + radian
nx = cos(radian1) * r + cx
ny = sin(radian1) * r + cy

其实这个平常都是用矩阵去做,好久没去自己推计算方式了

@belizer 多线程操作同一个对象并且调用相同的方法,为什么不会阻塞

这个问题的缘起是spring mvc默认是单例的,所以我产生了这样一个疑问,在高并发下,是单例模式效率高还是多例模式效率高?

之所以有这个疑问是因为我认为单例模式下,当一个请求在处理中的时候,接下来的请求会处于等待中(小白,大家勿笑)。之后有大神告诉我不会阻塞,因为web容器是多线程的。当时我觉得自己理解了。但之后我就咂摸这句话,是因为多线程所以不会阻塞。为什么多线程就不会阻塞呢?为什么多个线程操作同一个对象的同一个方法就不会阻塞呢?为什么多线程执行同一个对象的同一个方法中的相同代码不会阻塞呢?求教各位大神。

>>>@NO17

方法 存在JVM的一个内存区,这个方法区被各个线程共享。

打个不恰当的比方,如下:

老师在黑板上面写了一条1+1=?,同学们 同时看到信息后开始拿起笔计算。这里的黑板就相当于内存区,1+1=? 指令相当于方法,同学们相当于线程,大家一起并行计算,并没有阻塞。

那什么时候有阻塞?

老师说,谁要解答,请上讲台上来,这个时候可能会出现阻塞。

>>>@自由之信

感觉你说的问题,是两个问题,当多个请求发生的时候,采用多线程的模式,每一个线程处理一个或者多个请求,才能及时响应用户的请求。这个时候,每一个线程,都会访问 app 的这个实例的同一段代码,这段代码如果访问阻塞需要等待的资源,线程就可能阻塞,无论是单例,还是多例,都是一样的。

设计上用单例就能必然阻塞,多例就不会阻塞?不是的,线程阻塞是因为资源需要等待,不是因为这个关系。如果内存都是读的关系,就不存在竞争,如果内存的变化都是各自一份,也没有竞争(函数式编程)。

单例是一种设计模式,是为了软件容易维护,容易复用,容易测试才出现的,和阻塞不阻塞没因果联系。

>>>@乌龟壳

函数就像菜谱,不同线程就像不同厨师,能不能并行做菜和菜谱的性质本身无关,而是比如只有一个水龙头,菜谱要求每个厨师去接水,这个接水才会产生并发冲突

职业生涯问答

@琉璃梳 一个应届毕业生的迷茫

本人今年6月本科毕业,正在找工作,先介绍一下吧,自己学过Spring、Spring MVC、Springboot、JPA、Mybatis等一些常用框架,处于会用的阶段,搭建基础环境、CRUD都会。同时对软件测试也有了解,拿过一个软件测试的国奖。

自己用SpringBoot+Elasticsearch+Redis+Vue+Element UI做了一个文档管理以及搜索的前后端完全分离的项目,在学校期间也做过其他图书管理、在线商城的小项目。会看官方文档,查看英文API都没问题,文档管理的项目里面整合Elasticsearch的时候就是自己看英文API做的数据保存和全文搜索。

有实习经历,实习了有五个月,在实习公司主要做一些CRUD,接口对接,项目的版本更新、部署,项目的第一次部署是leader部署的。

然后说一下我的问题吧,本人想在厦门找份工作,当然杭州和深圳也可以,目前的状态是在学校网上投简历,在学校除了网上找工作,不知道应该做些什么,看《Java编程思想》也是断断续续。找工作的话,然后薪资应该在什么范围,比如在厦门应该找多少的,杭州和深圳应该找多少的。

望给个方向,提一些建议,不胜感激!!!感谢!

>>>@walykyy

找个正经八百的公司先干着吧,有经验再跳槽或者涨薪,不要把薪资待遇看的太重,给点钱能解决温饱就好了,当然给的多更好

>>>@迷途的码农

厦门不建议(房价和收入不成比例,it氛围也一般),感觉你会的蛮多,不知道深度如何,建议直接北上深杭都可以。接触一线城市it对自己起步也比较大帮助

>>>@粤利粤0

我当年花了一年把编程思想看了 8-10遍(当年专升本,本科上了半年就没课了,出去租房,买了 5000左右的书)发现看书是提升自己的基础了,但是和实际工作经验不对等,你需要有一些经验【老师傅的经验,常用的工具,他有完整的项目的经验,花一段时间学习】,之后在不懂的地方看书、之后循序渐进的提升,不要走弯路。(最好能进入一个好点的公司)

>>>@fjzsl

厦门是一线房价,二线城市,三线工资。工资跟上海深圳相比,你要打4折,跟杭州比要打6折。例如:你在上海深圳拿到15000元工资,你在厦门只能拿到6000元。最后说下,厦门真的适合养老生活,不适合上班工作。

@Cyclone丶 想离职,领导通过加薪挽留,需要继续呆吗?

金三银四的季节,想要离职,领导通过加薪来挽留,我现在7.5k,老板给我加到9K去,是一家创业公司;另外我也收到了一份9.5K的offer(转正后9.5+1000补助);该怎样选择呢?

>>>@魔力猫

如果是你已经主动提出来离职,那么不建议留下来。这种加薪挽留,除非是老板从别人那里听说了有人挖你(如果是你自己放风,也要小心不要让老板知道是你主动透露的,不然心眼小的一样记着),怕你真走了,主动找你谈加薪。其余大多数情况下,都是应急而已,嘴上挽留,可老板心里扎着刺呢。

这次离职,加薪留下来了。那么哪天又有另一家再提,我是不是还要加钱?这种情况下,老板大概率会赶快找替代品,你就是替代品到来前的临时备胎而已。到时候新人到了,找个理由把你处理掉。

主动离职你已经有了下家,可以无缝衔接。突然处理掉,弄不好就措手不及,要飘一段时间了。

>>>@原始数据

干几年了?为什么想走?因为工资低的话应该提出加薪请求,如果不加,果断离职。如果你下家公司没有试用期工资80%一说也可以过去,如果有的话,就考虑考虑得失。主要看你自己离职的目的。还有就是,it行业,你跳槽的过程就是你技术提高的过程。

你也希望自己的提问/回答上榜?欢迎大家前往>>>技术问答区,多多提问,多多回答~!

更多技术问题,尽在开源中国问答区

加载中
3
梅开源
梅开源

看不惯的代码就砍,是权力的狂欢,也是技术的毁灭。

1
loki_lan
loki_lan
该评论暂时无法显示,详情咨询 QQ 群:点此入群
局
也不无道理
小99
小99
对啊,至少要就一点空间给自己
1
刘志汉
刘志汉

while(1)

{

离职,跳槽,入坑,

}

1
风之武者qh1
风之武者qh1
我刚开始的时候巴不得所有业务逻辑写到数据库里面,现在巴不得所有业务写到代码里面。
1
开源中国首席路人王
开源中国首席路人王
都用存储过程的话那还用什么java。
J
Joden_He
不过老实说,数据库预编译的时候速度确实会快点,但是后期维护不好维护
1
encro
encro

@蓝水晶飞机

如果是只用一次的SQL(或者一天就运行一次的SQL):

你写了一个存储过程花了10多行几个小时性能执行时间1秒钟,

你老大一条语句花了5分钟不到执行时间5分钟,

那个厉害?你傲娇个啥?

J
Joden_He
好像很有道理哦!
0
邻里
邻里

为什么喜欢用存储过程,不好移植啊。我迁移数据库到别的平台还要重写。这样不累吗?

邻里
邻里
回复 @Joden_He : 对于有些人 process 是享受!
J
Joden_He
我也不喜欢proc
邻里
邻里
回复 @西红柿幽幽子 : 呵呵呵呵,对你冷眼一丿
西红柿幽幽子
西红柿幽幽子
回复 @邻里 : 你看你一辈子会不会遇到所谓的“某天”
邻里
邻里
回复 @西红柿幽幽子 : 你这只是小项目的看法!单一库种! 比如我用mysql写了个存储过程,用php调用的这个方法!虽然减轻了程序压力,却把压力给了数据库!但是某天我某个功能方法不存在mysql我觉得这种应该存在pgsql 或者 mogodb 那么请问,你的存储过程还能用不?程序要不要改?我迁移更换数据库,我顶多程序小改改,而你这还有存储过程,我却是大改改!
下一页
0
c
crystalsis

以前的习惯是把业务逻辑全写在数据库里,甚至再往前,是让数据库直接面向最终用户的,然后因为写sql难度大,所以也适合装

0
源码君
源码君
该评论暂时无法显示,详情咨询 QQ 群:点此入群
0
shijunti
shijunti
我觉得看项目的成长度,刚开始还不知道项目死活,就瞎写一通,项目大起来了就优化,如果死了就继续下一个项目,缺点就是数据太大的时候无法优化了
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部