JasonLaw 最近的时间轴更新 JasonLaw 最近的时间轴更新 |
JasonLawV2EX 第 484411 号会员，加入于 2020-04-17 11:42:03 +08:00今日活跃度排名 669 |
| 数据密集型应用系统设计 - 关于 Apache Avro 的疑问 程序员 • JasonLaw • 4 天前 • 最后回复来自 ky11223344 | 3 |
| MySQL InnoDB 的索引将 null 存储在哪里？
1 MySQL • JasonLaw • 3 天前 • 最后回复来自 louettagfh
|
9 |
| 不太理解 Redlock 算法中 split brain 相关内容 Redis • JasonLaw • 7 天前 • 最后回复来自 farseeraliens | 5 |
| 我对 Redlock 算法的疑问 Redis • JasonLaw • 6 天前 • 最后回复来自 wakzz | 15 |
| 大家的 MySQL 的事务隔离级别是 RR 还是 RC？为什么？ MySQL • JasonLaw • 12 天前 • 最后回复来自 iamaprin | 1 |
| Docker MySQL 如何设置事务隔离级别？ Docker • JasonLaw • 12 天前 • 最后回复来自 snachx | 1 |
| Jackson 如何保存 Map 中 key 的类型信息 Java • JasonLaw • 23 天前 • 最后回复来自 passerbytiny | 7 |
| MySQL InnoDB 是否在成功插入数据之后释放了插入意向锁？ MySQL • JasonLaw • 25 天前 • 最后回复来自 JasonLaw | 4 |
| Jackson 序列化时，如何将 final 类型的类型信息保存起来？ Java • JasonLaw • 26 天前 • 最后回复来自 JasonLaw | 6 |
JasonLaw 最近回复了
7 小时 0 分钟前 回复了 autoname 创建的主题 › MySQL › 环形 sql 主从同步， 3 台机子挂掉其中一台该怎么办 |
在“Designing Data-Intensive Applications - CHAPTER 5 Replication - Multi-Leader Replication - Multi-Leader Replication Topologies”中，介绍了三种不同 replication topologies：1. circular topology 2. star topology 3. all-to-all topology 。
它说“A problem with circular and star topologies is that if just one node fails, it can interrupt the flow of replication messages between other nodes, causing them to be unable to communicate until the node is fixed. The topology could be reconfigured to work around the failed node, but in most deployments such reconfiguration would have to be done manually. The fault tolerance of a more densely connected topology (such as all-to-all) is better because it allows messages to travel along different paths, avoiding a single point of failure.”，也就是说如果你继续采用 circular topology 的话，如果其中一个节点失败了，你可以重新配置 topology，你也可以选择容错性更好的 all-to-all topology 。
当然不同的 topologies 都有各自的优缺点，具体的话，你可以看一下“Designing Data-Intensive Applications”这本书。
顺便说一下，你这个根本不是主从同步，而是 Multi-Leader Replication 。
它说“A problem with circular and star topologies is that if just one node fails, it can interrupt the flow of replication messages between other nodes, causing them to be unable to communicate until the node is fixed. The topology could be reconfigured to work around the failed node, but in most deployments such reconfiguration would have to be done manually. The fault tolerance of a more densely connected topology (such as all-to-all) is better because it allows messages to travel along different paths, avoiding a single point of failure.”，也就是说如果你继续采用 circular topology 的话，如果其中一个节点失败了，你可以重新配置 topology，你也可以选择容错性更好的 all-to-all topology 。
当然不同的 topologies 都有各自的优缺点，具体的话，你可以看一下“Designing Data-Intensive Applications”这本书。
顺便说一下，你这个根本不是主从同步，而是 Multi-Leader Replication 。
18 小时 24 分钟前 回复了 sdfqwe 创建的主题 › MySQL › mysql 优化问题 |
18 小时 32 分钟前 回复了 sdfqwe 创建的主题 › MySQL › mysql 优化问题 |
@sdfqwe 你的表为什么是这样子的？
1. nodeId 已经是 PRIMARY KEY 了，为什么还要定义一个多余的索引 nodeid 呢？
2. 为什么不直接叫 id 和 parentId 呢？ nodeId 不会有什么业务含义吧？
3. 为什么城市表会有层级关系的呢？
1. nodeId 已经是 PRIMARY KEY 了，为什么还要定义一个多余的索引 nodeid 呢？
2. 为什么不直接叫 id 和 parentId 呢？ nodeId 不会有什么业务含义吧？
3. 为什么城市表会有层级关系的呢？
19 小时 30 分钟前 回复了 sdfqwe 创建的主题 › MySQL › mysql 优化问题 |
@sdfqwe #4 那就可以完全解释了，PRIMARY 和 nodeid 两个 index 相关的列都是 nodeid 。
1 天前 回复了 sdfqwe 创建的主题 › MySQL › mysql 优化问题 |
但是这无法解释第三和第四条语句会使用 PRIMARY 那个 index，难道 PRIMARY 和 nodeid 两个 index 相关的列都是 nodeid ？
提供多一点信息吧，表结构以及数据。不然无法知道什么原因。
提供多一点信息吧，表结构以及数据。不然无法知道什么原因。
1 天前 回复了 sdfqwe 创建的主题 › MySQL › mysql 优化问题 |
如果是的话，那就可以解释了。
查询优化器可能将 select b.* from b_city b where b.nodeid in (select a.nodeid from b_city a)转化为 select b.* from b_city b where
exists(select 1 from b_city a where a.nodeid = b.nodeid)，然后又转化为 select b.* from b_city b where
exists(select 1 from b_city a where a.id = b.id)，它的执行可以做到跟展示的执行计划匹配，可以逻辑地理解为“检查 b_city 的每一行，对于每一行，查询是否存在 id 为这行 id 的 b_city”。
至于为什么不限执行 select a.nodeid from b_city a，不管是怎样，你都要检查 b_city b 的每一行，相比于检查 b_city b 的每一行的 nodeid 是否存在于 select a.nodeid from b_city a 所代表的集合中，为什么不直接检查 b_city a 中是否存在 nodeid 为 b_city b 行 nodeid 的行呢？如果 nodeid 索引是唯一索引并且 nodeid 是 not null 的话，它甚至可以做到“检查 b_city b 的每一行，检查 b_city a 中是否存在 id 为 b_city b 行 id 的行”。
查询优化器可能将 select b.* from b_city b where b.nodeid in (select a.nodeid from b_city a)转化为 select b.* from b_city b where
exists(select 1 from b_city a where a.nodeid = b.nodeid)，然后又转化为 select b.* from b_city b where
exists(select 1 from b_city a where a.id = b.id)，它的执行可以做到跟展示的执行计划匹配，可以逻辑地理解为“检查 b_city 的每一行，对于每一行，查询是否存在 id 为这行 id 的 b_city”。
至于为什么不限执行 select a.nodeid from b_city a，不管是怎样，你都要检查 b_city b 的每一行，相比于检查 b_city b 的每一行的 nodeid 是否存在于 select a.nodeid from b_city a 所代表的集合中，为什么不直接检查 b_city a 中是否存在 nodeid 为 b_city b 行 nodeid 的行呢？如果 nodeid 索引是唯一索引并且 nodeid 是 not null 的话，它甚至可以做到“检查 b_city b 的每一行，检查 b_city a 中是否存在 id 为 b_city b 行 id 的行”。
1 天前 回复了 sdfqwe 创建的主题 › MySQL › mysql 优化问题 |
nodeid 索引是唯一索引并且 nodeid 是 not null 。对吗？
1 天前 回复了 zzhpeng 创建的主题 › MySQL › 大佬们求救，慢 SQL 问题 |
@kimqcn #55 “是不是 IS NULL=全表扫描”，可以看一下这个相关讨论 https://www.v2ex.com/t/694500 。
1 天前 回复了 zzhpeng 创建的主题 › MySQL › 大佬们求救，慢 SQL 问题 |
最近在看《数据密集型应用系统设计》，如果对你现在的情况合理的话，或许你应该分开 OLTP 和 OLAP 。
2 天前 回复了 zzhpeng 创建的主题 › MySQL › 大佬们求救，慢 SQL 问题 |
@zzhpeng #26
我主要是表达“条件为 is_virtual = 0，并且大多数的 is_virtual 都是 0”的时候，idx_storeid_isvirtual 其实是没有什么用处的。
你那条语句是直接在同一个环境运行的吗？如果是的话，单独运行肯定跟同其他语句并发运行是不一样的，我不清楚具体的情况，无法给你答案。
我主要是表达“条件为 is_virtual = 0，并且大多数的 is_virtual 都是 0”的时候，idx_storeid_isvirtual 其实是没有什么用处的。
你那条语句是直接在同一个环境运行的吗？如果是的话，单独运行肯定跟同其他语句并发运行是不一样的，我不清楚具体的情况，无法给你答案。
Select Language