@phplin 他这种应该是根据现有记录锁的.select * from `ttt` where `gap`=3 for update; 锁住的是
记录 insert into `ttt` values ('11111',1) 记为 A 记录 到 insert into `ttt` values ('11113',3) 为 B 记录 的区间 和
记录 insert into `ttt` values ('11113',3); 到 insert into `ttt` values ('11115',5) 记录为 C 区间 的区间.
只是粗略记作 (1,3] (3,5), 实际上是锁住比 A 记录大 到 B 记录的区间 和 比 C 记录小却比 B 记录大的区间。

比 A 记录 (11111,1 )大的记录，实际则是锁住 gap 非聚集索引 的 B+tree 在他右边的记录。 则实际上排序为
('11111',1);('11113',3);('11115',5); 所以当 gap=1 时锁住了大于 11111 的区间，同理 gap=5 也被锁住小于 11115 的区间。

总结文章，大家有兴趣可以看下 https://blog.csdn.net/u012087220/article/details/103716134

已解决

@junnplus 是真的耶，为什么呢

不论行业,学习方法是相通的. 其实大多数对这种伸手党的歧视,大多认为是嫉妒问题吧, 别人认为你可以不需要付出更多的代价就可以获得跟他至少一样的知识水平, 但是这些对'伸手党'本身是只有好没坏的, 就只会承受一些'罪名'罢了. 但是我相信一个真正的大神不会吝啬他的知识,他还巴不得有倾诉或者炫耀的对象(他真正在意的是那些不能用简单语言能轻易解释的知识). 急功近利 类似的也只是别人的一个结果论而已吧,你不必太在意别人的眼光, 怎么快怎么来, 只是通常 快 这个方法会导致知识离散, 掌握不牢固, 假如你针对这些克服了, 跟所谓正当途径的成果是相同的.

遇到一个问题, 最好是先想一下, 然后马上问大神, 然后借着大神回答你的内容进行思考, 然后得出自己的见解, 跟大神的见解对比,反馈给大神. 在反馈过程中,大神会觉得你是一个可教之才或者是一个有趣的小伙伴甚至能从你的见解得到更深的理解, 之前说的道德消耗就会被这个 所弥补. 所以是一个可持续的方法. 关键在于 请教后的有用反馈.

懒惰每个人都会有,但是每个人治理自己懒惰的方法不一样, 但是我更觉得这是个人问题,不是说你继续专研就一定能解决的. 1 楼讲的道理肯定在, 但是我可以认为是通俗之见,大多数人对你的劝告可能都是这样的,劝告你只能自学. 但是关键在于, 假如存在大神能指导你, 必定是只有好处没有坏处, 而又 '大神们'是惜时如金的, 所以问题在于你难找到大神对你指 导, 但是说不定哪天大神开心能对你指点 1,2, 或许你多年的困扰能直接被解决. 其实就是评估 你能找到大神的指点的代价 和 自学出来 的代价 之间的权衡.

我建议 当然要如 1 楼所说自学自规划为主,同时还要秉持找大神的态度(到后面你会发现别人说你伸手党, 但是我觉得伸手党只是消耗了别人对你的道德评价, 对你自己自身是只有好没有坏的. (有些人觉得说,不是自己研究出来的不深刻甚至不能掌握, 这可能说你并没有深刻理解大神的每一步所以才有这种情况, 试想,你所有的义务教育难道不就是对于古人做伸手党吗? 这种行为能让你省去大部分时间和研究路,必定是好的. 建议在道德评价允许范围内, 是能伸手你就伸手, 除非你是大大神.))

分页有 2 种,1 种是扶梯式, select * from xxx where id>xxx
2.第二种就是你这种精确分页了. select * from xxx limit xx,n

通常第二种大数量的时候性能会很差,带上分表可能会更复杂. 一般做法是对于 select * from xxx where xxx limit xxx,n
的查询, 进行多个分表同时查询 select * from xxx where xxx limit xxx,n, 对 m 个表查出来的最多 n*m 个数据进行人工排序,取前 n 个.

分治的思想,假如你要统计 10 天内的数据,你可以尝试每天跑脚本, 统计 1 天内数据,这样假如你统计 10 天只需要把 10 天内的统计数据相加就行了.

可以采用 hash(id) 进行分表或者分区, 分区的话开发容易. 这样尽管 1000 个用户 1000 个文章 100w 条还可以实现.

假如你单纯只是用来统计总阅读数和总时间,是否可以加上通过定时脚本定时合并数据库的数据, 例如你 mysql:
创建时间 文章 id 用户 id 阅读数 阅读时间
18 号 1 2 1 2m
19 号 2 2 1 7m
20 号 3 2 1 6m

定时脚本 20 号合并后产生汇总数据:
创建时间 文章 id 用户 id 阅读数 阅读时间
20 号 -1 2 3 15m
21 号 5 2 1 30m


这样类似定时清理旧数据. 类似 elasticsearch 之类的数据库都有隐藏后台合并数据的操作,elasticsearch 的是每个 index segement 是不可变的,然后会有很多,后台进程会自动错峰合并. 或者说是 lsm tree?

@Ehco1996 里面没有自己写的 c 库

我朋友很早已经跟我提到了.. 他说的是知乎, 每次他刚讨论完一个东西, 知乎就给他发这种东西.

时隔多天之后, 再次搜索这个问题, 发现一个很好的工具 pyrasite.

能生成 payload 监听一个随机端口, 然后通过远程线程注入代码的方式注入到该进程让进程执行然后连接到这个随机端口,接下来可以像 python cmd 互动式操作. (就是一个黑客里面的反向 shell)

安装后使用过程有一点曲折, 但是躺过了没啥问题, 接下来可以用 objgraph 等库进行远程注入. 然后发现只能看到某个类型的占用的最大, 具体到定位到源码行还有一定的差距. 现在还在查实

celery 也可以用协程 gevent 的, 所以其实你这 2 个感觉不能这么比着选

我理解你的协程是 tornado 进程里面的程序的协程吧. 这个问题当然是你能多进程多协程比多进程或者多线程号,所以能协程你就扔协程, 但是你说用 celery 其实还是一个队列解耦的一个好东西 . 要我选就选解耦微服务, 否则后面扩展很难

表结构要贴.... 首先, 你这个是一个 range 查询(in 是一种特殊的 range 查询, 两边值相等) ,会通过 range 优化器优化, 考虑使用 index dive(精确,会进去 b+tree 看节点数量,但是费时) 还是 index statistics.(通过索引的大致数量估算, analyse table 会精确这个数字, 当 range 数量过多会用他).(eq_range_index_dive_limit 决定了 range 数量大多少会用后者) 估算出来一个值,综合地估算了代价,包括了 io 等各种(还有是非聚集索引到聚集索引的代价), 来决定他使用哪个索引, 甚至直接走不命中的聚集索引,就是全表扫描. 不幸的是,优化器用了一个坏索引.

从你 force_index 来看, force_index 是不会走 range optimizer 了, 里面有一个 index condition 是覆盖索引的意思, 就是在通过非聚集索引查询的时候就过滤掉了部分数据,不需要再去聚集索引查询再检索过滤.

@334862132 你这句话的标点符号看的我有点蒙...我说的那个定时任务是, 通过 crontab 定时执行 py 脚本, 这个 py 脚本可以复用到 django 的 model(当然这样就是要初始化 django 运行环境了). 这样 crontab 就是 linux 系统自己的调度了.相关调度日志也是可以查看系统日志.