笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
MySQL 慢查询排查：先开慢日志拿真实 SQL，再 EXPLAIN 看索引，别瞎猜
线上 MySQL 偶发慢查询，接口超时。排查慢查询，最忌讳的是靠猜"哪个表没索引"然后乱加。正确流程：先让数据库自己把慢 SQL 记录下来，拿到真实执行的语句，再用 EXPLAIN 分析，最后对症加索引/改 SQL。
第一步：打开慢查询日志，让证据说话。 MySQL 默认不开慢日志，先确认并开启：
# 查看当前状态
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';
# 动态开启（重启失效，但排查期间够用）
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1; # 超过 1 秒的 SQL 记录（生产建议从 1-2s 起）
重启要永久生效的话写进 my.cnf：
[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = ON # 记录没走索引的查询（很有用）
log_queries_not_using_indexes 值得开，它能把"全表扫描"的 SQL 也记下来，往往比慢 SQL 更能暴露索引问题。
第二步：分析慢日志，找高频/最慢的。 慢日志格式类似：
# Query_time: 2.345 Lock_time: 0.001 Rows_sent: 10 Rows_examined: 500000
SET timestamp=...;
SELECT * FROM orders WHERE user_id=123 ORDER BY created_at DESC;
重点看两个指标：Query_time（执行总时长）、Rows_examined（扫描行数）。Rows_examined 远大于 Rows_sent 就是典型的缺索引/扫全表——扫描了 50 万行只返回 10 行。
用 mysqldumpslow 或 pt-query-digest 汇总出最该处理的 SQL（按总耗时/次数排序），别一条条肉眼看。
第三步：EXPLAIN 看执行计划，确认瓶颈。 拿着慢 SQL 用 EXPLAIN：
EXPLAIN SELECT * FROM orders WHERE user_id=123 ORDER BY created_at DESC;
重点看几列：
type：ALL（全表扫）是最差的；range/ref/eq_ref/const依次变好。key：实际用到的索引，如果是 NULL 说明没走索引。rows：预估扫描行数。Extra里出现Using filesort（排序没用上索引）、Using temporary（用了临时表）都要警惕。
第四步：对症处理。
type=ALL且 WHERE 的列没索引 → 加索引：
ALTER TABLE orders ADD INDEX idx_user (user_id);
ORDER BY触发 filesort → 让排序列进联合索引：ADD INDEX idx_user_time (user_id, created_at)，这样既能过滤又能用索引排序。WHERE 列 LIKE '%xxx%'前导通配符 → 索引用不上，改全文索引或换方案（这是设计问题不是加索引能解决的）。WHERE 函数(列)=...→ 对列用了函数索引失效，改写成对值用函数：WHERE created_at >= '2026-01-01'而不是WHERE YEAR(created_at)=2026。- 加了索引还是慢 → 看是不是没走新索引（用 FORCE INDEX 对比）、数据分布问题、或者 SQL 本身要重写（拆子查询、避免 SELECT * 但要的列多）。
几个高频坑：
WHERE user_id IN (大列表)+ 数据量大，索引也可能不高效，看是否该分批。- 联合索引最左前缀：
(a,b,c)索引，查询必须带 a 才能用上，只查 b 不走索引。 - 字符集不一致导致索引失效：两个表 join 的列一个 utf8 一个 utf8mb4，隐式转换让索引用不上（varchar 和 int 比也一样），
EXPLAIN里看得到。 - 加了索引要等后台建完（大表 ALTER 会锁/耗时，用 pt-online-schema-change 或 8.0 的 INSTANT 算法尽量减小影响）。
总结：慢查询排查 = 开慢日志拿真实 SQL → mysqldumpslow/pt-query-digest 汇总 → EXPLAIN 看 type/key/rows → 对症加索引或改 SQL。全程用数据说话，先看 Rows_examined 是不是爆炸，再让 EXPLAIN 告诉你索引哪没走对，别上来就全表加索引。