V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  billion  ›  全部回复第 15 页 / 共 45 页
回复总数  893
1 ... 11  12  13  14  15  16  17  18  19  20 ... 45  
@Keyes 尽量不用使用规则匹配来处理这个问题,否则就没有意义了。
2017-07-25 11:09:32 +08:00
回复了 mmmmmm 创建的主题 macOS 求打开文件的办法。给充 200 元话费
使用 Notepad++打开,尝试使用编码格式为 UTF-8, GBK, GB2312, GB18030.总有一个能正常显示。
2017-07-25 11:07:40 +08:00
回复了 shellfly 创建的主题 分享创造 (又)写了一个日语学习 app,邀请测试
楼主好人一生平安: [email protected]
@akira 第三条很重要。
@wdlth InnoDB
@specita 我怀疑应该是代码的问题。
@amghost 数据确实可能有重叠
@jarlyyn 正式代码里面就是这样的。这个帖子的代码经过精简。协程没有必要加锁吧,协程又不会发送读写冲突。
@nadoo 问题是,如果几个地方往 chan 写的速度很快。复杂提交事务的那个地方正在提交的过程中,此时另外 1000 个又来了,那就只有等待。
@nadoo 你这个想法很有意思。我去试一试。
@cloudzhou 我现在就是这样用的,速度大概 1-2 秒 1000 条记录
@msg7086 是远程的 MySQL
@nadoo 这个 chan 你可以理解为 Python 的 Queue。本来就应该是从 chan 里面读数据。
@specita 你也是用的 GO 语言吗?用的 MySQL driver 是 github.com/go-sql-driver/mysql 吗?
@jarlyyn 代码 1 更新 1000 条记录,用时 2 秒左右。代码 2 每个协程都需要大概 1 分钟才能更新 1000 条记录。
@jarlyyn 因为在生产环境里面的代码是分布在多个函数里面的,我这里把它们放在了一起。
@mansur 消费掉了的。channel 相当于 Python 里面的 queue,用一个少一个。
@sagaxu 应该是事务的问题。如果我把事务里面只执行 1 条语句,那么速度又可以达到大概 5 秒 1000 条。虽然还是没有直接执行快,但是已经显著超过在事务里面执行 1000 条。
1 ... 11  12  13  14  15  16  17  18  19  20 ... 45  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   938 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 20ms · UTC 20:45 · PVG 04:45 · LAX 12:45 · JFK 15:45
Developed with CodeLauncher
♥ Do have faith in what you're doing.