h0099 最近的时间轴更新 h0099 最近的时间轴更新
n0099_cn
n0099
n0099
| 如何从理论上避免这类并行任务交错执行时的冲突问题
1 程序员 • h0099 • 344 天前 • 最后回复来自 h0099
|
32 |
h0099 最近回复了
110 天前 回复了 chenqh 创建的主题 › 问与答 › 如何快速恢复重启前的应用呢? |
110 天前 回复了 iqoo 创建的主题 › 程序员 › 分享一个空间利用率超高的 Base36 算法 |
115 天前 回复了 lujiaxing 创建的主题 › 游戏开发 › 请教: 3D 游戏中的各种因碰撞而导致的角色/载具抖动, 抽搐甚至飞天是如何造成的? |
115 天前 回复了 lujiaxing 创建的主题 › 游戏开发 › 请教: 3D 游戏中的各种因碰撞而导致的角色/载具抖动, 抽搐甚至飞天是如何造成的? |
118 天前 回复了 drymonfidelia 创建的主题 › 程序员 › 为什么最流行的编码算法是刚好带两个符号破坏兼容性的 base64，而不是能够无视大小写的 base36、不带符号的 base62？这两个符号不仅严重影响兼容性使标准码表的 base64 不能直接拼在 url 中，还没有增加多少信息密度 |
141 天前 回复了 shendaowu 创建的主题 › MySQL › 求写一段生成数据库测试数据的代码 |
首先 19 个月过去了阁下还在折腾这个 https://en.wikipedia.org/wiki/Many-to-many_(data_model) 关系的 https://en.wikipedia.org/wiki/Associative_entity ？并试图继续滥用`提前优化` https://z.n0099.net/#narrow/near/93295 思维精神？
/t/908231
/t/908246
/t/909074
> 要么就是写入过程可以暂停和恢复，这个应该是没法实现的吧？
why not? 合理假设您是在 https://en.wikipedia.org/wiki/Cunningham's_Law
> 分段写入也可以，通过参数决定写入多少
这跟前面的可暂停本质上是一样的
> 写入速度越快越好，最好可以最大化利用 SSD
建议直接`LOAD csv` https://dev.mysql.com/doc/refman/8.4/en/load-data.html
并在写入前后开关 redolog https://dev.mysql.com/doc/refman/8.4/en/innodb-redo-log.html#innodb-disable-redo-logging
> 最好是几天时间能写入一千万行吧。如果没必要的话更少也可以。
一千万行？一千万亿行！
---
```sql
CREATE TABLE tag_content_rel(
rel_id INT PRIMARY KEY AUTO_INCREMENT,
tag_id INT NOT NULL,
content_id INT NOT NULL);
```
为什么不`UNIQUE(tag_id, content_id)`？还是说您的确需要允许出现重复的`(tag_id, content_id)`对?
> 我猜如果位置是有规律的可能查询性能会更好
对于将 PK 用做 clustered index （详见 https://github.com/n0099/open-tbm/issues/48#issuecomment-2091811880 的`12.1`）的 mysql innodb storage engine 中的表`tag_content_rel`只有`PRIMARY KEY(rel_id, tag_id, content_id)`后才会符合您的假设
/t/908231
/t/908246
/t/909074
> 要么就是写入过程可以暂停和恢复，这个应该是没法实现的吧？
why not? 合理假设您是在 https://en.wikipedia.org/wiki/Cunningham's_Law
> 分段写入也可以，通过参数决定写入多少
这跟前面的可暂停本质上是一样的
> 写入速度越快越好，最好可以最大化利用 SSD
建议直接`LOAD csv` https://dev.mysql.com/doc/refman/8.4/en/load-data.html
并在写入前后开关 redolog https://dev.mysql.com/doc/refman/8.4/en/innodb-redo-log.html#innodb-disable-redo-logging
> 最好是几天时间能写入一千万行吧。如果没必要的话更少也可以。
一千万行？一千万亿行！
---
```sql
CREATE TABLE tag_content_rel(
rel_id INT PRIMARY KEY AUTO_INCREMENT,
tag_id INT NOT NULL,
content_id INT NOT NULL);
```
为什么不`UNIQUE(tag_id, content_id)`？还是说您的确需要允许出现重复的`(tag_id, content_id)`对?
> 我猜如果位置是有规律的可能查询性能会更好
对于将 PK 用做 clustered index （详见 https://github.com/n0099/open-tbm/issues/48#issuecomment-2091811880 的`12.1`）的 mysql innodb storage engine 中的表`tag_content_rel`只有`PRIMARY KEY(rel_id, tag_id, content_id)`后才会符合您的假设
251 天前 回复了 netabare 创建的主题 › 程序员 › 这年头，参与开源项目还要付费才能参加了吗 |
343 天前 回复了 alexfarm 创建的主题 › MySQL › ON DUPLICATE KEY UPDATE 引起的死锁问题，求助一下 |
如果单独只看您发的那坨`SHOW ENGINE INNODB STATUS`deadlock detection log 的话那当时场景就是
session2 先执行因而持有着`(bid, sid, oid)`
```
RECORD LOCKS space id 270 page no 6338 n bits 352 index idx_bid_sid_oid of table db.tb trx id 7367656999 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 13 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
```
上的末端`(某值, +∞)`[`nextkey`]( https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-next-key-locks)X 锁因为有[`hex 73757072656d756d; asc supremum`]( https://en.wikipedia.org/wiki/Infimum_and_supremum) https://dev.mysql.com/blog-archive/innodb-data-locking-part-2-5-locks-deeper-dive/
而后执行的 session1 也在尝试 acquire`(bid, sid, oid)=('444444', '555555', '666666')`上的 recordlockX 锁但由于其位于 session2 的`nextkey`X 锁范围中而等待
```
RECORD LOCKS space id 270 page no 6338 n bits 352 index idx_bid_sid_oid of table db.tb trx id 7367657071 lock_mode X waiting Record lock, heap no 13 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
```
当 session1 在等待时 session2 也开始等待 PK （但下面的约束不是在`PRIMARY KEY (id)`上而是`INSERT`中的其他字段可能因为其是`AUTO_INCREMENT`AI 而您也没显式指定其值所以无法`WHERE`）`(bid, sid, oid, emark, amark, bmark, cmark)=('444444', '555555', '666666', '00', '00', '00', '00')`上的[recordlock(有`but not gap`)]( https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-record-locks)X 锁
```
RECORD LOCKS space id 270 page no 7273 n bits 88 index PRIMARY of table db.tb trx id 7367656999 lock_mode X locks rec but not gap waiting
[...]
3: len 25; hex 4f4243574830315a3032363631323032333132323241303536; asc 444444;;
4: len 10; hex 30313939373333303331; asc 555555;;
5: len 6; hex 363733353839; asc 666666;;
[...]
```
所以是互相等待对方而被 deadlock detection 并决定 rollback 后来的 session1 让 session2 先过
```
2023-12-28T19:00:05.140247+08:00 3180165 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (1)
```
session2 先执行因而持有着`(bid, sid, oid)`
```
RECORD LOCKS space id 270 page no 6338 n bits 352 index idx_bid_sid_oid of table db.tb trx id 7367656999 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 13 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
```
上的末端`(某值, +∞)`[`nextkey`]( https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-next-key-locks)X 锁因为有[`hex 73757072656d756d; asc supremum`]( https://en.wikipedia.org/wiki/Infimum_and_supremum) https://dev.mysql.com/blog-archive/innodb-data-locking-part-2-5-locks-deeper-dive/
而后执行的 session1 也在尝试 acquire`(bid, sid, oid)=('444444', '555555', '666666')`上的 recordlockX 锁但由于其位于 session2 的`nextkey`X 锁范围中而等待
```
RECORD LOCKS space id 270 page no 6338 n bits 352 index idx_bid_sid_oid of table db.tb trx id 7367657071 lock_mode X waiting Record lock, heap no 13 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
```
当 session1 在等待时 session2 也开始等待 PK （但下面的约束不是在`PRIMARY KEY (id)`上而是`INSERT`中的其他字段可能因为其是`AUTO_INCREMENT`AI 而您也没显式指定其值所以无法`WHERE`）`(bid, sid, oid, emark, amark, bmark, cmark)=('444444', '555555', '666666', '00', '00', '00', '00')`上的[recordlock(有`but not gap`)]( https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-record-locks)X 锁
```
RECORD LOCKS space id 270 page no 7273 n bits 88 index PRIMARY of table db.tb trx id 7367656999 lock_mode X locks rec but not gap waiting
[...]
3: len 25; hex 4f4243574830315a3032363631323032333132323241303536; asc 444444;;
4: len 10; hex 30313939373333303331; asc 555555;;
5: len 6; hex 363733353839; asc 666666;;
[...]
```
所以是互相等待对方而被 deadlock detection 并决定 rollback 后来的 session1 让 session2 先过
```
2023-12-28T19:00:05.140247+08:00 3180165 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (1)
```
Select Language