cs8814336 最近的时间轴更新 cs8814336 最近的时间轴更新 | cs8814336后端 V2EX 第 384013 号会员，加入于 2019-02-15 10:00:04 +08:00 |
广州
| nginx + django + uwsgi + python2.7 如何排查内存泄露. 2 Python cs8814336 2019 年 12 月 27 日 最后回复来自 cs8814336 | 12 |
| 为什么索引等相同下,数据量到达一定量级时候， 会听说 mongodb 比 mysql 快. 1 MySQL cs8814336 2019 年 3 月 5 日 最后回复来自 cs8814336 | 73 |
| mysql next-key lock 问题 MySQL cs8814336 2020 年 3 月 25 日 最后回复来自 cs8814336 | 28 |
cs8814336 最近回复了
2020 年 3 月 25 日 回复了 cs8814336 创建的主题 MySQL mysql next-key lock 问题 |
@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 的区间。
记录 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 的区间。
2019 年 12 月 27 日 回复了 cs8814336 创建的主题 Python nginx + django + uwsgi + python2.7 如何排查内存泄露. |
总结文章，大家有兴趣可以看下 https://blog.csdn.net/u012087220/article/details/103716134
2019 年 12 月 26 日 回复了 cs8814336 创建的主题 Python nginx + django + uwsgi + python2.7 如何排查内存泄露. |
已解决
2019 年 9 月 20 日 回复了 silenceeeee 创建的主题 MySQL MySQL next-key lock 请教 |
2019 年 9 月 20 日 回复了 cs8814336 创建的主题 MySQL mysql next-key lock 问题 |
div class="reply_content">@junnplus 是真的耶，为什么呢
不论行业,学习方法是相通的. 其实大多数对这种伸手党的歧视,大多认为是嫉妒问题吧, 别人认为你可以不需要付出更多的代价就可以获得跟他至少一样的知识水平, 但是这些对'伸手党'本身是只有好没坏的, 就只会承受一些'罪名'罢了. 但是我相信一个真正的大神不会吝啬他的知识,他还巴不得有倾诉或者炫耀的对象(他真正在意的是那些不能用简单语言能轻易解释的知识). 急功近利 类似的也只是别人的一个结果论而已吧,你不必太在意别人的眼光, 怎么快怎么来, 只是通常 快 这个方法会导致知识离散, 掌握不牢固, 假如你针对这些克服了, 跟所谓正当途径的成果是相同的.
遇到一个问题, 最好是先想一下, 然后马上问大神, 然后借着大神回答你的内容进行思考, 然后得出自己的见解, 跟大神的见解对比,反馈给大神. 在反馈过程中,大神会觉得你是一个可教之才或者是一个有趣的小伙伴甚至能从你的见解得到更深的理解, 之前说的道德消耗就会被这个 所弥补. 所以是一个可持续的方法. 关键在于 请教后的有用反馈.
懒惰每个人都会有,但是每个人治理自己懒惰的方法不一样, 但是我更觉得这是个人问题,不是说你继续专研就一定能解决的. 1 楼讲的道理肯定在, 但是我可以认为是通俗之见,大多数人对你的劝告可能都是这样的,劝告你只能自学. 但是关键在于, 假如存在大神能指导你, 必定是只有好处没有坏处, 而又 '大神们'是惜时如金的, 所以问题在于你难找到大神对你指 导, 但是说不定哪天大神开心能对你指点 1,2, 或许你多年的困扰能直接被解决. 其实就是评估 你能找到大神的指点的代价 和 自学出来 的代价 之间的权衡.
我建议 当然要如 1 楼所说自学自规划为主,同时还要秉持找大神的态度(到后面你会发现别人说你伸手党, 但是我觉得伸手党只是消耗了别人对你的道德评价, 对你自己自身是只有好没有坏的. (有些人觉得说,不是自己研究出来的不深刻甚至不能掌握, 这可能说你并没有深刻理解大神的每一步所以才有这种情况, 试想,你所有的义务教育难道不就是对于古人做伸手党吗? 这种行为能让你省去大部分时间和研究路,必定是好的. 建议在道德评价允许范围内, 是能伸手你就伸手, 除非你是大大神.))
我建议 当然要如 1 楼所说自学自规划为主,同时还要秉持找大神的态度(到后面你会发现别人说你伸手党, 但是我觉得伸手党只是消耗了别人对你的道德评价, 对你自己自身是只有好没有坏的. (有些人觉得说,不是自己研究出来的不深刻甚至不能掌握, 这可能说你并没有深刻理解大神的每一步所以才有这种情况, 试想,你所有的义务教育难道不就是对于古人做伸手党吗? 这种行为能让你省去大部分时间和研究路,必定是好的. 建议在道德评价允许范围内, 是能伸手你就伸手, 除非你是大大神.))
2019 年 4 月 18 日 回复了 Boywus 创建的主题 MySQL Mysql 千万级数据在后台管理的展示问题 |
分页有 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 个.
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 个.
2019 年 4 月 18 日 回复了 blueorange 创建的主题 MySQL mysql 统计优化技巧 |
分治的思想,假如你要统计 10 天内的数据,你可以尝试每天跑脚本, 统计 1 天内数据,这样假如你统计 10 天只需要把 10 天内的统计数据相加就行了.
Select Language