V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  512357301  ›  全部回复第 50 页 / 共 53 页
回复总数  1049
1 ... 42  43  44  45  46  47  48  49  50  51 ... 53  
2021-08-06 22:09:37 +08:00
回复了 singerll 创建的主题 问与答 请教一下海量数据的查询方案
行数太多,得分表,保持一个表 200-600 万行,加索引,并且约束好要查询的范围,确定好要查询哪张表(一般对应分表方案有对应的中间件的吧),这样秒级是可以的,基本就是单机单表的标准速度了
金山的云文档,可以在线打开 Excel,类似腾讯文档,你可以看下是否支持透视表。如果不支持,那基本上没有合适的了
个人看法:这种低代码开发方式跟之前 jq 时代的 easyui 有相同的问题——框架本身就很复杂,甚至比自己手写组件还复杂。
有开发能力的觉得束手束脚不想用,没开发能力的学了半天,哪天发现 amis 项目被百度放弃了,导致不敢用。
2021-08-02 17:41:49 +08:00
回复了 xinJang 创建的主题 程序员 远程控制安卓手机(小米)有问
https://mp.weixin.qq.com/s/rgxnX5UJcZUKHOCBtGwwjw
阿虚同学推荐的第二种方法:teamviewer,次数多了有被判断为商用的可能,不过日常使用没问题
@enchilada2020 commit 的目的就是记录你的思路,开源嘛,让别人也能知道你的代码变动过程。
一次性完整写完再 commit 大可不必,一次性完整写完我觉得那应该叫发版或者大版本,这里面肯定应该有无数个小版本来支撑的
2021-08-01 20:35:00 +08:00
回复了 3dwelcome 创建的主题 分享发现 这年头写个漫画爬虫都心力憔悴。
@3dwelcome 那就做个打码接口呢,把验证码传回到邮箱或者任意地方,并通知你,你通过指定的接口把验证码文本回传给爬虫,然后爬虫模拟输入。
不过这种无法对付那种点击或者滑块的验证码
2021-07-31 18:03:22 +08:00
回复了 overthemoon 创建的主题 程序员 奇葩的需求
这不是组长要求的,这是需求方要求的,我是需求方我也这么要求,这种导入方式才是最符合认知的,但也是最增加开发工作量的。。。,一般这种需求在产品调研阶段就被产品经理怼回去了,压根不会到研发,现在只能说明需求方比较强势😂
导入的字段数量介于必选字段数量和总字段数量之间,且对字段顺序不做要求
你想象一下前端小弟有没有在调用 web 接口传参的也跟你商量这样来传参呢,每次只传需要的参数,参数顺序不按照你规定的来,而是随机排列😉
2021-07-30 21:07:58 +08:00
回复了 lifesimple 创建的主题 程序员 你们用宜搭么,用了宜搭开始加班,感觉好难用
谢谢踩坑,幸亏当初没尝试。。。
这种平台就是给一线运营人员用的,会点 Excel 公式的运营人员
帆软才是给技术人员用的低代码开发平台。。。
我啰嗦一句哈,不在一起睡会导致感情问题,虽然世事无绝对,但是一起睡并且互相适应对方的睡觉习惯也确实是增进感情最快速的方式。
具体了解下说脱口秀的思文和程璐。
这么大的房子,肯定也很有钱了,我一个屌丝也没资格指手画脚,只是希望把自己想说的说出来罢了
2021-07-30 20:34:42 +08:00
回复了 yishen0 创建的主题 Node.js sequelize、mysql 问题求解答!一张表多个关联关系问题。
试试这个:

select
t0.*
,t1.name
,t2.name
from work_task t0
left join worker as t1 on t0.other_worker_id = t1.id
left join worker as t2 on t0.worker_id = t2.id
2021-07-26 22:26:31 +08:00
回复了 Ma4cus 创建的主题 京东 之前注销了京东白条,现在恢复不了了。。
这种一般注销的时候他们就把后路堵死了,注销会有协议,甚至电话录音,就怕你反悔,毕竟跟钱相关的,注销过的在他们理解就是有二次注销甚至跑路风险的,你虽然不跑路,但估计注销二次注册跑路的人比较多,所以风控法务才会这么干,否则谁也不介意多个用户的,对吧。
@bclerdx 微信,TEpMaXM0MDQ=这个是题主的微信号经过 base64 编码后的内容,随便找个 base64 解码网站就能解开
2021-07-25 18:28:51 +08:00
回复了 Junzhou 创建的主题 NAS 群晖 NAS 有异常的网络发送,数据量巨大,暂时未定位到原因。
有个笨办法,换端口,并且只限制某几个端口可以连外网,类似于 vps 的安全组。
我之前在 aws 搭的 win10 就出现过这种情况,怀疑是被当成肉鸡了,后来在安全组限制入站端口后,瞬间风平浪静,(不过最终也不确定是什么原因导致的,也可能是 win10 自动更新的锅)
aws ec2 每月限制 15G 的进和出流量,我当时竟然能跑满。。。,限制端口后,每个月顶天了 8 个 G
2021-07-23 21:27:53 +08:00
回复了 zealinux 创建的主题 macOS Mac 上微信占有空间 32GB,该怎样清理?
把所有的聊天记录备份一下,然后卸载重装微信,然后回复聊天记录。
手机上可以这么搞,电脑上你试试
2021-07-22 20:40:36 +08:00
回复了 superJava 创建的主题 奇思妙想 唉,突然感觉拉丁语系的开发人员不用切输入法太爽了
能理解你的爽点,现在写 SQL,越来越感叹英文的字段名真是好,不用打字,连反折号也不用打,爽!
不用切输入法我的理解应该是默认输入一种语言(比如中文),然后通过一种方式来解决输入另外一种语言的问题,比如回车就自动变成英文了。
需要这里面的难点我理解是标点符号的输入(引号逗号等)以及方法参数的智能提示问题,解决了这两点,就能实现不切输入法了
2021-07-20 21:00:36 +08:00
回复了 Skeleies 创建的主题 互联网 Foxmail 问题
@ReputationZh 杀后台重启 foxmail
2021-07-18 23:23:39 +08:00
回复了 DavZhn 创建的主题 MySQL 不懂就问: mysql 中大数据量日环比计算时间太久
最后半段需要更正下:

//缩小数据的查询范围
where t2.day between REPLACE(DATE_SUB(CONCAT(#{year},'-',#{month},'-',01), INTERVAL 1 DAY ),"-","") and concat(#{year},#{month},#{day})
) y ON t.day = y.tomorrow
where t.day between concat(#{year},#{month},01) and concat(#{year},#{month},#{day})
order by t.day
2021-07-18 19:07:23 +08:00
回复了 DavZhn 创建的主题 MySQL 不懂就问: mysql 中大数据量日环比计算时间太久
最后半段需要更正下:

//缩小数据的查询范围
where t2.day between REPLACE(DATE_SUB(CONCAT(#{year},'-',#{month},'-',01), INTERVAL 1 DAY ),"-","") and concat(#{year},#{month},#{day})
) y ON t.day = y.tomorrow
2021-07-18 19:04:39 +08:00
回复了 DavZhn 创建的主题 MySQL 不懂就问: mysql 中大数据量日环比计算时间太久
这是我写的 SQL(不过一次只能查一天的):

SELECT
right(t.day,2) AS day_of_month,
sum(if(day = 20210716,CONVERT(t.R11,DECIMAL),1,0)) as qiantian_num,
sum(if(day = 20210717,CONVERT(t.R11,DECIMAL),1,0)) as zuotian_num,
sum(if(day = 20210717,CONVERT(t.R11,DECIMAL),1,0)) / sum(if(day = 20210716,CONVERT(t.R11,DECIMAL),1,0)) -1 as huanbi
concat(round(sum(if(day = 20210717,CONVERT(t.R11,DECIMAL),1,0)) / sum(if(day = 20210716,CONVERT(t.R11,DECIMAL),1,0)) -1,4)*100,'%') as huanbi_baifenbi
FROM 原始数据表 t
where t.day between 20210716 and 20210715
group by right(t.day,2)


如果只是改你的原始 SQL 的话,我觉得应该这么改下,可能会快一些:
SELECT
right(t.day,2) AS day,
CONVERT (t.R11 , DECIMAL) as num,
y.R11 ynum,
CASE
WHEN y.R11 IS NULL OR y.R11 = 0 THEN 0.00 ELSE round((t.R11/y.R11)-1, 2 )
END cc
FROM 原始数据表 t
LEFT JOIN(
SELECT
REPLACE(date_add( day, INTERVAL 1 DAY ),"-","") tomorrow
,CONVERT (R11,DECIMAL) as R11
FROM 原始数据表 t2
//缩小数据的查询范围
where t2.day between REPLACE(DATE_SUB(CONCAT(#{year},'-',#{month},'-',01),"-",""), INTERVAL 1 DAY ) and concat(#{year},#{month},#{day})
) y ON t.day = y.tomorrow
where t.day between concat(#{year},#{month},01) and concat(#{year},#{month},#{day})
order by t.day
2021-07-18 00:31:28 +08:00
回复了 DavZhn 创建的主题 MySQL 不懂就问: mysql 中大数据量日环比计算时间太久
今天太晚了,我先说个思路,明天中午补 SQL,可以考虑一次性把 2 天的数据都取出来,然后在 select 的时候,用 sum(if(day=今天,1,0))的方式求和今天的数量,用 sum(if(day=昨天,1,0))的方式求和昨天的数量,然后第三个字段是环比
这样就不用子查询和 left join 了

(如果我刚才那个思路不行,只是针对你放出来的这个 SQL 来说,from 后面那个子查询和 left 后面那个子查询你都没限制时间范围,那么理论上会全表查询的,合计扫描两遍。。。,全表查完之后,你对派生表限制了时间范围,还是用函数计算的 day 。。。,你可以用>=或者<=啊,这样也会快一些)
1 ... 42  43  44  45  46  47  48  49  50  51 ... 53  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2527 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 37ms · UTC 07:52 · PVG 15:52 · LAX 00:52 · JFK 03:52
Developed with CodeLauncher
♥ Do have faith in what you're doing.