wenxueywx 最近的时间轴更新 wenxueywx 最近的时间轴更新 |
wenxueywxV2EX 第 583288 号会员，加入于 2022-05-30 11:35:10 +08:00今日活跃度排名 7266 |
wenxueywx 最近回复了
9 小时 11 分钟前 回复了 rqxiao 创建的主题 › MySQL › 请教一个 Mysql 并发查询的问题（与可重复读相关？） |
@rqxiao 1 、“rr 等级的 readview 是事务开始时创建”确实不对，准确地说，rr 等级的 readview 创建时机是事务中首次执行 sql 时，此事务中的快照读都是基于该 readview 。
2 、A 、B 两个并行的事务，A 可以通过当前读获取 B 事务已经提交的数据，不能通过快照读读到。
3 、 加锁和 count 读是两个操作，count 依然是读的快照，不会因为你加锁而读最新数据，你需要 count 进行当前读
2 、A 、B 两个并行的事务，A 可以通过当前读获取 B 事务已经提交的数据，不能通过快照读读到。
3 、 加锁和 count 读是两个操作，count 依然是读的快照，不会因为你加锁而读最新数据，你需要 count 进行当前读
1 天前 回复了 kokoushinn 创建的主题 › MySQL › 请教各位一个困扰我已久的问题 mysql 运行 sql 文件十分的慢 |
你可以将虚拟机硬盘换成 ssd 试试
1 天前 回复了 kokoushinn 创建的主题 › MySQL › 请教各位一个困扰我已久的问题 mysql 运行 sql 文件十分的慢 |
虚拟机与物理机磁盘是一样的？再看看 mysql 内存配置 redo log 、binlog 落盘策略
1 天前 回复了 rqxiao 创建的主题 › MySQL › 请教一个 Mysql 并发查询的问题（与可重复读相关？） |
rr 等级的 readview 是事务开始时创建，事务在整个生命周期内使用相同的 readview 。我理解题主的意思是 A 、B 两个事务并行，A 事务已经提交的数据，B 事务是通过 readview 是读不到的。查询子表状态时采用当前读可以解决：select count(0) from a_detail WHERE auid = 'a1' and approval_status!=2 lock in share mode ；
其次，主表没有加锁的必要
其次，主表没有加锁的必要
1 天前 回复了 zcm3579 创建的主题 › MySQL › 请教 SQL 子查询的性能问题 |
“在 where 里写条件会影响 GROUP_CONCAT 的结果”
是什么意思？
是什么意思？
7 天前 回复了 lasuar 创建的主题 › MySQL › 请教关于 mysql 临键锁工作模式的问题 |
查询走的全表扫描吧
你 explain 看看
你 explain 看看
7 天前 回复了 lasuar 创建的主题 › MySQL › 请教关于 mysql 临键锁工作模式的问题 |
SELECT * FROM students_nk_lock WHERE score >= 90 FOR UPDATE;
17 天前 回复了 Zaden 创建的主题 › MySQL › mysql 如何高效获取两条相邻推送时间间隔 |
加个字段 last_push_time 记录上一次推送时间，insert 时可以通过触发器查询上一次该 point_id 的 push_time 来更新
17 天前 回复了 main1234 创建的主题 › MySQL › mysql 组合索引在范围查询和 order 下到达能不能用到索引 |
1 、select * from info where a = 1 and c = 200
multi 索引总长度为 15 字节，可以用到 multi 索引的 a 字段（ 5 字节），不能用到 c 字段（不满足最左前缀匹配原则）；
icp 开启的情况下，可以把 c=200 的条件下推到引擎层过滤，可以减少回表次数
2 、select * from info where a > 1 and b < 200
首先，即使使用索引+icp ，也是和场景 1 相同，只能使用 multi 中 a 字段的索引，b<200 作为条件下推。
实际上，根据索引中 a 字段的基数来判断，只有在使用索引能大量减少扫描的行时才会使用索引+下推；假设表中有 10W 行数据，a 字段的取值范围是 1-100 ，在数据分布均匀的情况下，a 字段的基数为 1000 ，当你使用 a>1 and b<200 时，使用 multi 索引查询基本是全索引扫描+icp ，然后回表；全索引扫描代价与全表扫描差别不大；而当你使用 a>95 and b<200 时，通过 multi 索引的 a 字段可以过滤 95%的行，代价肯定比全表低。
multi 索引总长度为 15 字节，可以用到 multi 索引的 a 字段（ 5 字节），不能用到 c 字段（不满足最左前缀匹配原则）；
icp 开启的情况下，可以把 c=200 的条件下推到引擎层过滤，可以减少回表次数
2 、select * from info where a > 1 and b < 200
首先，即使使用索引+icp ，也是和场景 1 相同，只能使用 multi 中 a 字段的索引，b<200 作为条件下推。
实际上，根据索引中 a 字段的基数来判断，只有在使用索引能大量减少扫描的行时才会使用索引+下推；假设表中有 10W 行数据，a 字段的取值范围是 1-100 ，在数据分布均匀的情况下，a 字段的基数为 1000 ，当你使用 a>1 and b<200 时，使用 multi 索引查询基本是全索引扫描+icp ，然后回表；全索引扫描代价与全表扫描差别不大；而当你使用 a>95 and b<200 时，通过 multi 索引的 a 字段可以过滤 95%的行，代价肯定比全表低。
Select Language