Pollardb 对同一条记录先update，然后马上select没有查到原因总结
会话一致性 可以参考 https://help.aliyun.com/document_detail/99093.html
看看这种情况，是不是属于一个会话呢？
一个应用中 先执行update一条记录，然后再查这条记录。
用了数据库连接池，
如果 update操作时，用的是 数据库连接1
select时，用的是 数据库连接2
====
这不是一个会话。
会话 一致性 同一个session内，一定能够查询到读请求执行前已更新的数据
如果对 数据要求 严格 这种情况可以尝试一下全局一致性
如果这两个操作放到一个数据库事务中，这种情况下，是不是在同一个pollarDb的会话中了？
是的，使用事务后，事务内的所有与数据库的操作都是使用相同的连接，并且事务场景pollarDB会路由到rw节点
也就是说，放在同一个 事务中就能立马查到了
请求转发逻辑
可读可写模式转发逻辑如下：- 只发往主节点：
- 所有DML操作（INSERT、UPDATE、DELETE、SELECT FOR UPDATE）。
- 所有DDL操作（建表或库、删表或库、变更表结构、权限等）。
- 所有事务中的请求。
- 用户自定义函数。
- 存储过程。
- EXECUTE语句。
- Multi Statements。
- 使用到临时表的请求。
- SELECT last_insert_id()。
- 所有对用户变量的查询和更改。
- KILL（SQL语句中的KILL，非命令KILL）。
同一个会话 与同一个数据库连接 之间，是什么关系呢？
连接是物理层级的，是数据库客户端与服务器之间一条具体的TCP连接；
会话则是逻辑层级的，是一个领域语言，是数据库连接在DDD中的描述，对应的是数据库连接
譬如，可以这样说：mysql客户端直连实例后，就是一个会话，一个会话里面可以执行多条语句 如果是多个客户端连接到实例，就是多个会话，一个会话里面的语句，通常会话一致性不会有太多问题，但是有严格的上下逻辑的sql，一般都是建议放在事务里面，这样proxy也不会去做拆分
如果是长链接的话，会话不断基本一直在用一个会话，一般的话，应用先到应用的连接池，然后连接池再使用长连接 连接到数据库。咱们当前的业务场景，建议使用事务，或者使用hint的方式更合适，后续遇到这种对延迟敏感类型的业务，走hint比较稳一些
连接不能关联到具体的lsn号，只能根据您的业务需要 ，调整一致性级别的设置，PolarDB一致性级别越高，集群性能越低
会话一致性就是 在 一个 回话里，插入完 立马就找到了
这个地方需要改现有sql，针对一些orm中间件自动生成sql的场景，就比较难办
读写分离他是根据sql类型和事务的情况来做判断的，前一个为select被路由到ro节点后，接下来的update，根据路由规则会直接到rw节点；
对同一条记录，update后，select不到最新的数据，有两种情况：
1、update没有提交，另起的会话进行查询，隔离级别为RC，这时候查不到属于正常，因为update的操作本身没提交
2、update提交了，但是另起会话查询没有最新的数据，这个是因为ro和rw多少会有一点延迟，如果想拿到最新的数据，需要去rw节点，或者业务侧使用事务让查询只路由到rw
