@SgtPepper 我本来就是想用二层交换机扩展主路由，使主路由+可 vlan 交换机=三层交换机

@anubu 2 个 vlan 间基本没有通讯的需求，但如果 2 个 vlan 都接入了同一个 dhcp 分配同一个子网段（也就是划分后分别连入主路由的 lan 口），那么理论上 2 个 vlan 间可以通过主路由通讯？其实我不知道这种连接是否正确，上面的尝试 1 和尝试 3 的结果使我感到很多疑惑，我对 vlan 的理解是划分后就变成两个简易的交换机？

@SgtPepper 那不如再搞个路由器，连接 B 地设备和二层交换机？

@swulling 那可能是您的理解吧

@swulling 我在网络抓包的时候，明显看到有设备不停地在局域网内广播，特别是智能家具设备

@FabricPath 我就是想做 Vlan 啊，需要一个三层交换机的意思是指需要为 vlan 设置一个网段？

@swulling 初衷有提及

明朝那些事，听完

@hhhhhh123 技术在于折腾，不要放弃。有点怀疑是不是数据库工具没有帮你真正开到第二个会话，可以在 update 之后，在另一个会话界面执行一下“SELECT pk_money FROM user_basic_info WHERE uid = 123456803 for update ;” 正常某个会话锁了某行，另一个会话再尝试加锁，就会出现阻塞等待，可以用这一点判断一下是否在新的会话中。

@hhhhhh123 set autocommit=0 在 begin 前

很简单，让甲方提高自己的业务量吧

我觉得缩进应该尽量用于“美化代码”，而尽量不要并且最好干脆不要参与“语法结构定义”的逻辑里。

关于“新会话就是 + 1”也表示怀疑，建议再认真测试一次，在 InnoDB 引擎的表，执行“不会放图片。。。。”后面的代码块的“COMMIT”之前，再确保开了新的会话，直接执行 select （不要 for update ）,能把图贴上来，或者语句+结果文字贴上来就行。这种试验，已经给多位新入职同事科普过了。

@BeforeTooLate 阿里云还是有 https 请求次数收费的，虽然有资源包计费模式

@Abbeyok 学会了没有门路也是白学

确实很多都无用，重点不是工具，而是资源管理和资源

内容创作就行，比如来自摄影，绘画

@CRVV

我确实一直都在用 MySQL 做项目，其他数据库甚少了解。现今中小项目使用 MySQL 依然很普遍。
对关系型数据库的学习，我一直都是以“边用边学”的方式，有尝试去“系统性进阶学习”，但很难看进去（比如《高性能 MySQL 》），或者说是还没找到适合的教材、方法吧。
产品经理的需求，我觉得技术经理需要去进行平衡，当然要优先考虑实现需求，在不是 100%实现需求的情况下，实现的方式有多种。

@CRVV 如果按你说的场景并且只能局限于此，的确只能 BigQuery 了。但我还是比较好奇在实际场景中，遇到这种 BigQuery 是几乎开放式的（多用户或多进程可同时进行请求），这时候还能这么搞？（我实际项目中反而遇到很多这种用户可能会频繁访问 BigQuery 的情景）
我理解中的“分步处理”不是为了“代码比较好懂”而是为了“不让 mysql 高负荷运行复杂查询“，维护简单的 sql 查询比较容易（比如简单的索引组合，分表之类），但 BigQuery 的查询维护就变得很难把控。
在结合一些实际业务情况，我或者会考虑这些：
1 、针对查询业务做一个汇总表，并动态更新，这相当于持久化的热缓存了；
2 、尽量减少搜素条件需求，或针对搜索条件对分步查询进行调整；
3 、慎重考虑分页。分析 BigQuery 过程其实很多情况下（特别是排序），sql 已经把相关数据全部扫描了，然后我们只取部分数据（估计考虑数据传输压力到中间层），我觉得这种情况不如“不分页查询”。数据库和中间层之间数据传输压力（如 in 查询的数量限制也算是），可以尝试在分步处理的各个步骤当中再进行”分步查询“，中间层和客户端层之间的传输压力，那就甩锅给带宽吧（ nginx 已经有数据压缩传输处理了，不想管了）
总结我对 BigQuery 的使用场景是：业务量不大，且让业务快速到位。
以上，个人鄙见