pymysql 默认的 autocommit 是 false，不 commit 是不能查询到新的数据的，你可以设置为 true 或者每次查询完 commit

@huijiewei #52 真正使用其实并不需要，其实有点类似乐观锁之类的，就算短时不一致，问题也不大

其实两者其实并没有什么区别
session 现在如果存在服务器大多也会使用 redis 这样分布式存储方式，不存在不能横向扩展的问题，再者 session 也并不是一定要保存在服务器，完全可以加密放到 cookie 里
jwt 也并不是没有问题，比如正常情况下要比 session_id 更大，需要消耗更多流量，挤占更多带宽，已经无法在服务端注销，那么久很难解决劫持问题
此外 jwt 一般只会直接保存用户 id 这样信息，那么正常情况下还是需要用户更多信息，那么同样需要 redis 这样高效率缓存系统配合，那么效率上也并不能比 session 更高效

@twoyuan #14 是的，但是这种标签似乎所有标签发出的信息都是一样的，不能携带信息啊

mysql statistics 这个的提示似乎就是正在从磁盘读取数据的意思吧

大量数据要翻页一般不使用页码，而是使用游标，游标那么久可以包含很多信息了，当前页码，翻页方向，当前 id 值，每页条数等等，使用的方式 where id>last_id offset per_page_count，这样就可以充分使用索引来翻页了

@realpg #7
@liuminghao233 #8 先肯定是要校时的啊，还用说，否则多人怎么确认都是在同一个画面上啊

@ryd994 #9 其实我也是这么想的，天线直接反馈不同信号代表不同 id，这样造到几分钱应该问题不大吧，完全可以代替二维码，同时对机器阅读又很友好

@mlhorizon #6 但是搜了很多都是 3 毛钱以上的，没有找到很便宜的啊

@am241 #1
@boboliu #3
这个是很方便很便宜，就一点不好，识别麻烦了些，比如仓库里东西随便放在货架上，想用无人设备直接开始盘点很难

@kaixuanzxw #28 bigbang，onestep 这些更多是依赖用户分享，还有输入框的复制接口，都是需要用户触发的，哪有像你们是的不管场景，不管用户同意不同意，不管现在是不是合适就直接开始抓取的，这明显是已经我是造刀的还是拿着刀去杀人的区别的了吧

@louzhumuyou #5 这种语法 2.7 肯定用不了啊，否则 3 和 2.7 的兼容问题不是被你解决了

@swulling #1 然而这个值似乎没有什么参考价值啊

在视频里直播二维码么？每帧一个二维码，收到视频数据之后再用编码器解码得到每帧数据，再解析二维码内容，恩，搞定，中间多少次压缩多少次转码都不怕。。。

前几天有时可以随随便便都跑到七八十 M，但是发现代理处理速度反而跟不上完全卡死了，也是跪了。。。

@aricch #2 不过比起 dota 真实弱智太多了，技能明显比物理攻击强太多了，推塔带来的收益十分的少，基本很难有什么策略性可言，不过这倒是对赚钱和赚取新用户十分有利。。。