V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  LiaoMatt  ›  全部回复第 2 页 / 共 4 页
回复总数  77
1  2  3  4  
很有意思
@shockingFly 确实
@huangcjmail 底层只要是 B+树就可以这么分析, 思想是趋同的
@FlyingBackscratc 应该就是 sid_date_time 联合索引 sid 基数太少导致, 你使用 >=是无法利用组合索引的, sid 的基数太少, 需要扫描的页过多, 而且你是取所有数据, 还需要回表, 数据库引擎觉得全表扫描的成本比通过 sid + 索引下推 + 回表的成本低, 所以选择全表扫描
可能是 sid 作为索引基数太小了, 数据不够分散导致? 可以看下 optimize trace 分析
你们公司还招人不, 让我来吧, 这老哥的操作听起来就很迷, 很有必要做一下 codereview
数据补偿
recover
应该是用 java.lang.instrument.Instrumentation 或者 Java TI, 前者的可能性更大一点, Idea 热更新好像不能修改类成员信息, 不然会更新失败
稍微有点卡, 但是总的还是变顺畅了一些
@drymonfidelia 8 * 500W 就是 4000 万了- -, 你可以试着把 join 的表去掉, 看看单表查询效率
@salmon5 Tomcat 很多其实是 IO 密集型请求, 为了降低响应时间, 这么做可以理解, 因为客户端还等着呢, 每个场景有自己测重点; JUC 牺牲一点实时性, 减少系统资源消耗, 在异步执行实时性要求不高的任务, 这个设计挺好的
假设的有十个并发任务需要处理, 每个任务需要 10ms, 当前核心线程池是 5, 用队列的理想时间是 20ms, 不需要创建销毁线程, 如果立马增加 5 个线程, 处理的理想时间大概是 10ms, 空闲后需要销毁, 如果类似的场景很多, 就需要频繁的创建销毁, 用队列可以做到削峰平谷, 避免以上场景造成的线程创建销毁的开销
我觉得是因为任务应该很快就可以被处理, 在队列里留存的时间很短, 所以可以先不创建新的线程, 直到队列满了表现出线程池的计算能力真的不够用了, 再启动线程去消费队列, Doug Lea 觉得这样处理适用于大部分场景吧
你说的索引失效是指 C 表全表扫描了吗
问题 1: 你的表有些索引的基数太低了, 效率不高, 比如 CodeStatusId, packageId, 看 cardinality 这个字段, 数字越大数据越分散越好, 如果基数太小, MySQL 可能会觉得不用索引效率更高, 建议合并或者删除一些索引; 问题 2: 都是 inner join 会产生, ,每次都要创建临时表, 做文件排序, 可以尝试通过子查询或者其他方式写. MySQL 本身提供 optimizer_trace 功能, 但是需要开启, 可以看到 MySQL 分析结果,不过 RDS 怎么搞还没弄过
这也能上钩
3.你认为解决高并发问题的本质是什么?
我认为是解决客户端体验一致性问题, 因为客户端不能理解为什么并发高低会影响服务, 对于客户端来说, 它希望服务端的表现不要偏离这个预期, 偏离这个预期就算破坏了客户端体验的一致性;
247 天前
回复了 unt 创建的主题 程序员 请问有没有好用的 Go MQTT Broker
@qloog 差点颠覆我 RabbitMQ 三观
可能因为引入了行内自动补全导致资源消耗变大了
253 天前
回复了 Ainokiseki 创建的主题 MySQL 求问关于并发更新数据库的潜在数据冲突
不论隔离级别是啥都不允许脏写, update 是当前读, 你的条件会加间隙锁,其他的事务会阻塞,直到事务提交,或者超时
1  2  3  4  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2706 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 26ms · UTC 11:42 · PVG 19:42 · LAX 03:42 · JFK 06:42
Developed with CodeLauncher
♥ Do have faith in what you're doing.