笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
从库延迟 16 个小时追不上：大事务和并行复制
主从延迟这个事，以前一直觉得离自己很远，直到某天从库延迟到了五万八千多秒，也就是 16 个小时，才认真把原理和并行复制啃了一遍。
环境是 MySQL 5.7.38 一主一从，业务读写都在主库，从库只跑报表和一些只读接口。某天下午报表数据不对，上去查：
SHOW SLAVE STATUS\G
重点看三行：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 58642
IO 线程和 SQL 线程都显示 Yes，但回放已经落后了 58642 秒。IO 线程其实正常，binlog 已经拉到从库的 relay log 里了，卡就卡在 SQL 线程这边执行不过来。
先怀疑从库机器性能不行，上去看了 CPU、磁盘都正常，就是 SQL 线程在单线程硬扛。5.7 的并行复制默认是关的，slave_parallel_workers 默认 0，等于主库多线程并发写，从库一个线程串行回放。只要主库写量大一点，从库就必然越拉越远，这是 5.7 的单线程复制老问题。
再定位落后那段时间主库到底写了什么。翻主库 binlog 里的大事务：
SHOW BINLOG EVENTS IN 'mysql-bin.000123' LIMIT 5;
发现一个超大事务：某条批量 UPDATE 一次改了八百多万行，事务从开始到提交跑了一刻钟。这种大事务在主库执行多久，从库回放就要多久，而且它执行期间排它锁一直占着，后面排队的几千个小事务全被堵住，延迟瞬间就上去了。
处理分两步。立即的动作是打开并行复制，让从库多线程回放：
STOP SLAVE;
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL slave_parallel_workers = 8;
START SLAVE;
LOGICAL_CLOCK 是 5.7 基于 binlog 提交时间戳的并行复制策略，把同一时刻提交、互相没有锁冲突的事务分给多个 worker 并行回放，对主库高并发小事务的场景提升非常明显。改完观察 Seconds_Behind_Master，能肉眼看到往下掉，大概半小时追平了。
根上的处理是让业务别在生产库跑一次动几百万行的大事务。那个批量 UPDATE 是运营后台的“全量改状态”功能，没做分批。改成循环一批 5000 行、提交一次之后，主库 binlog 里不再出现超大事务，从库也就不会被单个事务卡住。这个经验后来也推广到所有后台批量任务：凡是 update 超过几万行的，一律分批加 sleep，宁可慢一点也别制造大事务。
定位大事务除了翻 binlog，还有更早的预警办法：在库上定期查 information_schema.innodb_trx，找出 trx_rows_modified 特别大的事务：
SELECT trx_id, trx_state, trx_started, trx_rows_modified
FROM information_schema.innodb_trx
ORDER BY trx_rows_modified DESC LIMIT 10;
trx_rows_modified 上百万的基本就是罪魁祸首，把对应会话找到、跟业务确认能不能停，比等它跑完再收拾强。这个查询后来做成了每天凌晨扫一次的脚本，专盯批处理时段有没有大事务，有就告警。关于并行复制再补一句：LOGICAL_CLOCK 能并行回放的前提是主库 binlog 里事务的 last_committed 能对齐，如果主库本身写并发就低、事务都是串行提交，并行复制也救不了，延迟高就先怀疑主库是不是有什么东西把写请求全串行化了。我们那次主库正常几百 TPS，纯属大事务把后面所有事务挤成一条队，是特例。worker 线程数也要跟从库 CPU 核数匹配，8 个 worker 放 4 核从库不一定更快，反而增加上下文切换，我最后是试出来的：先 4 后 8，这台 8 核实例上 8 最快，就留了 8。
补充几个这次学到的判断细节。Seconds_Behind_Master 这个值本身不靠谱：它是 SQL 线程当前执行事务的时间戳和 IO 线程最新拉到事件的时间戳之间的估计差，如果两个线程都闲着，它可能显示 0，但 relay log 里其实还压着没执行的；另外 SQL 线程卡在同一个大事务里时，时间戳不推进，这个值甚至可能不涨反而不变。所以判断延迟不能只看它一个，要配合 Relay_Log_Pos 和 Exec_Master_Log_Pos 的差距一起看，两个位点差得多才是真落后。8.0 里命令改名 SHOW REPLICA STATUS，参数叫 replica_parallel_workers，概念一样。5.7 和 8.0 之间并行复制的默认值差异我没细究，反正 5.7 默认不开并行这个坑是实打实踩过的。