h0099 最近的时间轴更新 h0099 最近的时间轴更新h0099's repos on GitHub
Java · 24 人关注
tbclient.protobuf
从 244 个历史版本百度贴吧客户端中提取出的所有 Protocol Buffers 定义文件 `.proto`
HTML · 16 人关注
httpErrorPage
自定义HTTP错误页
C# · 9 人关注
open-tbm
4 人关注
TouhouCannonBall-Live2d-Models
https://drive.google.com/drive/folders/1tqZ2aJ9dU_ZolDV4xWsV_rqiCRYJKS4-
PHP · 2 人关注
bilibiliVote
bilibili吧2019年吧主公投原始数据
Java · 2 人关注
GTCE-5.10.41
GregTech rewrite for modern versions of Minecraft
2 人关注
Network-Addon-Mod-Install-Options
SC4 NAM33 自定义安装选项 录入/翻译/截图 http://git.oschina.net/n0099/Network-Addon-Mod-Install-Options
2 人关注
open-tbclient
293 个历史版本百度贴吧客户端中的所有 `.java` 文件
Shell · 1 人关注
iobench.sh
Just another simple wrapper over `sysbench fileio` to output a table of common metrics
1 人关注
n0099
1 人关注
Tieba-SimCity
模拟城市吧吧规及导航
0 人关注
archive-TiebaLite
https://web.archive.org/web/20240217185947/https://github.com/HuanCheng65/TiebaLite
Shell · 0 人关注
azcopy_sanoid_zfs_snapshot.sh
Shell · 0 人关注
azure_root-on-zfs_migration.sh
0 人关注
bbcode
[READ ONLY] Subtree split of Flarum bbcode extension.
TypeScript · 0 人关注
berry
📦🐈 Active development trunk for Yarn ⚒
Shell · 0 人关注
docker-zulip
Container configurations, images, and examples for Zulip.
PHP · 0 人关注
DoctrineExtensions
A set of Doctrine 2 extensions
PHP · 0 人关注
flarum-ext-auth-steam
Flarum Steam Login extension
0 人关注
flarum-redis
Redis cache and queue for @flarum
JavaScript · 0 人关注
level-ranks
Add a level/expierence bar to your flarum Forum.
C# · 0 人关注
nsonic
NSonic is an open-source .NET client implementation for the Sonic search backend.
C# · 0 人关注
opencvsharp
OpenCV wrapper for .NET
0 人关注
osu-skin-CloverRemix
C++ · 0 人关注
PaddleOCRSharp
This project is modified and encapsulated by C++ code based on Baidu PaddlePaddle OCR. Net class library. It includes the table recognition function of text recognition, text detection and statistical analysis based on text detection results. At the same time, it is optimized to improve the recognition accuracy in the case of inaccurate small image
0 人关注
pdiff
TypeScript · 0 人关注
res
Visual Basic · 0 人关注
SC4AutoInstallerAndLauncher
模拟城市4 豪华版 自动安装程序及启动器 源代码
0 人关注
signature
✍️ Add signature support to your Flarum forum.
Dockerfile · 0 人关注
siye-srv-ops
n0099_cn
n0099
n0099
| 如何从理论上避免这类并行任务交错执行时的冲突问题
1 程序员 • h0099 • 339 天前 • 最后回复来自 h0099
|
32 |
h0099 最近回复了
105 天前 回复了 chenqh 创建的主题 › 问与答 › 如何快速恢复重启前的应用呢? |
105 天前 回复了 iqoo 创建的主题 › 程序员 › 分享一个空间利用率超高的 Base36 算法 |
110 天前 回复了 lujiaxing 创建的主题 › 游戏开发 › 请教: 3D 游戏中的各种因碰撞而导致的角色/载具抖动, 抽搐甚至飞天是如何造成的? |
110 天前 回复了 lujiaxing 创建的主题 › 游戏开发 › 请教: 3D 游戏中的各种因碰撞而导致的角色/载具抖动, 抽搐甚至飞天是如何造成的? |
114 天前 回复了 drymonfidelia 创建的主题 › 程序员 › 为什么最流行的编码算法是刚好带两个符号破坏兼容性的 base64，而不是能够无视大小写的 base36、不带符号的 base62？这两个符号不仅严重影响兼容性使标准码表的 base64 不能直接拼在 url 中，还没有增加多少信息密度 |
136 天前 回复了 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)`后才会符合您的假设
247 天前 回复了 netabare 创建的主题 › 程序员 › 这年头，参与开源项目还要付费才能参加了吗 |
339 天前 回复了 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