202503

VXX 交易

分析买入远期实值VXX put的可行性，考虑

  • 波动率大多时候的走势，以及极端时候的走势，
  • 入场和出场时机。
  • 胜率，盈亏比

下面是一种分析框架，用以评估买入远期实值VXX看跌期权（Put）的可行性，结合波动率走势、入场出场时机、胜率及盈亏比等因素：

1. 波动率走势分析

常态下的波动率表现

  • 大部分时间：
    • 市场波动率大多处于温和水平，VXX因Contango效应存在时间价值消耗，价格长期呈下降趋势。
    • 在这种环境下，VXX价格下跌比较稳定，若买入远期实值看跌期权（内在价值较高，且时间溢价较低），期权价格会随着标的物缓慢下跌而逐步获利，但涨幅有限。

极端市场情况

  • 极端情况下：
    • 突发性市场事件（如金融危机、地缘政治风险、重大经济数据意外等）会导致市场恐慌，波动性急剧飙升，从而推高VXX价格。
    • 在这种情形下，买入看跌期权可能面临亏损风险，因为VXX价格逆势上行。此外，极端行情下市场流动性可能骤降，期权价格波动加剧，交易成本上升。

2. 入场和出场时机

入场时机

  • 理想入场条件：
    • 低隐含波动率环境： 当市场波动率处于较低水平，隐含波动率较低时，买入看跌期权成本相对便宜。
    • 技术面确认下行趋势： 观察VXX处于长期下跌趋势或处于关键阻力位附近，确认没有短期反弹迹象。
    • 事件周期判断： 在市场情绪相对平稳期介入，避免在市场转向前即被卷入突发事件。

出场时机

  • 目标设定和风险控制：
    • 渐进止盈： 若VXX价格如预期逐步下跌，可考虑部分平仓锁定收益。
    • 止损机制： 若市场突然转向或波动性上升（标志着VXX可能反转上行），应及时止损离场。
    • 事件驱动离场： 若市场出现重大风险事件，考虑提前平仓保护本金。

3. 胜率与盈亏比

胜率考量

  • 历史表现：
    • 从历史数据看，VXX因其设计和结构特性（Contango和滚动损耗）长期呈下降趋势，在正常市场环境下采用看跌策略可能具有较高的胜率。
    • 然而，在波动率爆发的极端市场情景下，标的价格急剧上行可能导致策略失效。因此，胜率很大程度上依赖于市场环境及事件周期的判断。

盈亏比评估

  • 内在价值与时间价值：
    • 买入实值远期看跌期权，本质上成本较高，但内在价值较大，能在VXX缓慢下跌时获得稳定收益。
    • 盈亏比主要取决于入场成本、时间溢价和持有期间市场波动变化。
  • 理想条件下：
    • 若按照计划持有并成功规避极端波动风险，盈亏比有望维持在1:2甚至更高，即风险较低的情况下获取较为稳健的回报。
  • 风险预估：
    • 如果市场突发性逆转，上涨剧烈，则可能出现较大亏损，此时盈亏比大幅恶化。因此，必须严控风险和设定止损点。

4. 综合评估

  • 优势：

    • 利用VXX长期下行趋势，在正常市场环境中，买入远期实值看跌期权能较好捕捉标的下跌收益。
    • 实值期权内在价值较高，受时间价值消耗影响相对较小，胜率在稳态市场中相对较高。

  • 风险：

    • 市场极端波动和突发事件可能使策略逆转，导致较大损失。
    • 选择合适的入场和出场时机至关重要，否则可能在市场反转前被套或遭遇流动性风险。

  • 策略建议：

    • 结合技术指标与宏观事件判断，设定明确入场条件；
    • 同时制定严格的风险管理计划（止损位、仓位控制、动态调整）；
    • 可以考虑配合其他对冲策略（如适量持有反向ETF或其他波动率产品）平衡潜在风险。

总结

买入远期实值VXX看跌期权在理论上可利用VXX长期下行趋势获得正收益，胜率在正常市场环境中较高、盈亏比较理想，但极端事件风险始终存在。因此，策略的成功依赖于对市场波动率走势的准确判断、恰当的入场出场时机把握以及严格的风险管理。交易者应进行充分的模拟测试与数据回测，确保策略在不同市场情景下的稳定性。

因为买的是远期的put，比如一年之后到期，如果在这期间，比如6个月后发生了黑天鹅事件，这时候如何操作，清仓，继续持有，还是加仓。
考虑黑天鹅引起的波动率升高最终会下降。

在持有一年到期的远期VXX看跌期权时，黑天鹅事件可能会带来短期内波动率急升，这通常会推高VXX价格，从而对看跌期权形成短期的不利影响。不过，黑天鹅事件过后，市场波动率通常会迅速回落甚至低于事件前的水平，从而使VXX重回长期下行轨道。基于这种预期，以下是几种操作思路和建议：

1. 分析黑天鹅事件的影响

  • 短期波动率急升

    • 在黑天鹅事件爆发时，市场恐慌可能使隐含波动率急剧上升，导致看跌期权的时间价值和波动率溢价上升，但同时标的VXX价格可能因为情绪驱动而短暂上行，进而对期权内在价值造成负面影响。

  • 事件后的波动率回落

    • 黑天鹅事件通常是突发性危机，其后波动率会出现“峰值”然后迅速收敛。这意味着从长期来看，VXX可能会因持续的Contango和滚动损耗重新走低。

2. 操作策略建议

A. 部分清仓或减仓

  • 目的：在黑天鹅事件爆发后，先部分兑现部分利润或控制风险。
  • 优点：如果事件导致期权短期内价格波动，你可以通过部分平仓锁定已有的正收益，同时保留部分头寸以待事件后波动率回落时获得更大收益。
  • 注意事项：在清仓部分头寸时，应考虑到手续费、流动性以及未来的市场走势，确保不会过早退出未来反弹带来的收益机会。

B. 继续持有等待回落

  • 目的：如果你对市场波动率回落和VXX长期下行的判断非常坚定，可以选择继续持有头寸。
  • 优点：持有远期期权能够充分捕捉到黑天鹅事件后VXX价格回落带来的收益。
  • 风险：短期波动可能会导致期权价格波动较大，期间需要有较强的心理承受能力，并且需要预留充足的风险资金以防止中途被迫平仓。

C. 加仓策略

  • 条件：只有在价格回调到合理水平且市场情绪趋于平稳时，才可以考虑加仓。
  • 优点：加仓可以降低平均持仓成本，进一步放大未来市场回归时的收益。
  • 风险提示：在黑天鹅事件初期加仓风险较大，因为波动率仍然处于高位，市场情绪不稳定，加仓容易遇到“抛售陷阱”。建议等待市场明确转向后再考虑加仓。

3. 入场与出场时机的再考量

  • 短期内风险控制

    • 可以设置动态止损或者目标价位，及时锁定短期收益，避免市场波动带来的情绪性决策。

  • 观察市场情绪和波动率指标

    • 关注VIX等波动率指数及市场流动性情况，判断何时开始出现波动率回落的迹象，再考虑调整持仓比例。

  • 定期评估头寸

    • 定期（如每月或每季度）回顾持仓策略，特别是对于远期产品，需要确保当前策略仍与市场基本面和技术面相符。

4. 综合建议

总体来说，面对黑天鹅事件时的操作应谨慎应对：

  • 短期内建议：视市场情况，考虑部分平仓以锁定已有收益，同时保留部分头寸等待事件后的波动率回归；
  • 中长期持有：如果对市场长期下行和VXX衰减趋势有充分信心，可以继续持有，但需要做好心理和资金上的准备；
  • 加仓操作：建议在市场情绪明朗、波动率明显回落之后，再考虑适量加仓，以优化持仓成本。

每种操作都有其风险和收益特点，关键在于实时观察市场情绪和波动率变化，并根据个人风险承受能力和交易策略做出灵活调整。

因为买入远期实质PUT的成本比较高，而且持有时间长，遇到黑天鹅的概率比较高，但因为VXX长期下行，所以是一个大概率赚小钱，小概率亏大钱的策略，但因为是期权买方，风险是有限的，所以管理好仓位，是能得到长期稳定收益的。

这么理解正确吗？

你的理解大体正确，但也需要注意一些细微风险和市场现实情况：

  • 高买入成本与时间价值消耗：远期深度实值PUT价格较高，长时间持有会带来较高的时间价值消耗（Theta），在平稳下跌过程中可能只赚取小额利润。

  • 大概率赚小钱、小概率亏大钱的特性：正如你所说，利用VXX长期下行趋势，这一策略在大部分时间内能获得小额收益，但在遇到黑天鹅或极端市场事件时，损失可能会迅速扩大。

  • 期权买方风险有限：作为买方，亏损风险确实是有限的（最多损失初始投入），但高昂的成本和波动率风险依然需要精细管理。

  • 仓位管理与风险控制：通过合理的仓位控制、止损策略以及对市场情绪的实时判断，可以在降低极端风险的同时捕捉长期的收益。

总的来说，你对策略的理解是正确的，但实际操作中需要特别关注时间价值侵蚀、市场极端波动以及流动性风险，确保策略在各种市场环境下都能经受考验。

在大多情况下vxx Contango和滚动损耗得到的收益能否抵消掉时间价值损耗，如果我买入1年后到期的实值 vxx put，如果在到期前平仓的话，大概率是赚钱还是亏钱？

从理论上讲，如果市场基本保持稳定且VXX长期处于Contango状态，其滚动损耗会推动VXX逐步下跌，这种下跌趋势可能会转化为期权的内在价值增长，从而部分抵消时间价值（Theta）的消耗。对于一份一年后到期的实值VXX看跌期权，如果你在到期前平仓，主要考量因素包括：

  • 内在价值增加：在大部分平稳或温和下跌的市场环境中，由于VXX的结构性滚动损耗，标的价格会逐渐下跌，使得看跌期权内在价值增加。

  • 时间价值损耗：深度实值期权的Theta相对较低，但持有时间较长仍然会面临时间价值的侵蚀，尤其在市场波动性较低时，这部分成本可能不完全被内在价值的增长所覆盖。

  • 波动率环境：如果隐含波动率保持在较低水平，则期权价格对时间价值敏感度较高；反之，在波动率飙升时，期权价格可能短期逆势上涨，但整体趋势依旧取决于VXX的长期走向。

  • 平仓时机：若能在市场短期波动过后等待到内在价值充分累积，再选择平仓，则大概率能够锁定收益；但若在市场出现短期反弹或黑天鹅事件期间急于平仓，则可能因波动率变化而造成亏损。

综合来看，在大部分情况下，假设市场保持整体温和且VXX持续因Contango效应走低，买入一年后到期的实值VXX看跌期权并在适当时机平仓，盈利的可能性较高（赚取小额稳定收益），但也存在极端事件导致亏损的风险。策略本质上是大概率赚小钱、小概率亏大钱，但由于期权买方的最大风险限定于初始投入，因此如果你能合理管理仓位、严控风险并选择合适的出场时机，整体上实现长期稳定的正收益是有可能的。

买入远期实质vxx put，赚够钱就提前平仓，中间遇到黑天鹅就等着，黑天鹅迟早会过去，波动率肯定会迅速下降，就变是黑天鹅引起了超级大的波动率上升，因为是期权买方，风险是可控的，如果是轻仓的话，亏不了多少钱。感觉这个策略胜率很高，能大概率赚小钱，而且小概率亏大钱时风险也是可控的。

分析这个策略

这套策略的核心思路是利用VXX因Contango和滚动损耗导致的长期下行趋势，采用买入远期实质看跌期权（PUT）的方式，从而在大部分时间内赚取小额利润；同时，由于期权买方的风险仅限于期权成本，因此即便在遇到黑天鹅事件时，持有者也能通过等待市场波动率的回落来恢复长期看跌趋势。下面从几个关键点对这一策略进行分析：

1. 策略优势

  • 长期趋势匹配
    VXX因Contango和滚动损耗长期走低，在正常市场环境下，远期实质看跌期权的内在价值会随着VXX价格下跌逐步增加，从而实现盈利。

  • 风险有限
    作为期权买方，最大亏损仅为期权的初始投入。如果采用轻仓操作，即使出现极端情况，损失也在可控范围内。

  • 高胜率、小额收益
    策略设定为在VXX稳步下跌时赚取小额利润，赚够钱就提前平仓，这种逐步获利、风险可控的模式，在大部分正常市场条件下有较高的胜率。

2. 黑天鹅事件的影响

  • 短期逆势冲击
    黑天鹅事件往往引发市场恐慌，导致波动率急剧上升，VXX价格可能短期内反弹。此时，持有看跌期权的头寸可能出现暂时性的账面亏损。

  • 波动率回落后的恢复
    根据预期，黑天鹅引起的高波动率只是暂时现象，随着市场情绪恢复和波动率迅速下降，VXX价格会回到长期下行轨道。这时，看跌期权的内在价值有望恢复，从而弥补之前的损失。

  • 持仓耐心要求
    面对黑天鹅事件，策略要求交易者有足够的耐心和资金管理能力，避免因短期波动而被迫平仓。等待市场情绪平稳后再择机平仓是关键。

3. 盈亏比与风险管理

  • 收益特点
    在正常市场环境下，策略大概率赚取小额利润，通过提前平仓实现逐步获利；但在遇到极端事件时，亏损可能会比较明显（小概率亏大钱），但由于亏损上限仅限于期权成本，整体风险是有限的。

  • 时间价值侵蚀
    远期期权虽然因实值部分较高而减缓Theta损耗，但长时间持有仍然需要关注时间价值的侵蚀。如果市场没有明显下跌，期权成本可能逐渐蒸发。

  • 仓位控制
    鉴于黑天鹅事件的不可预测性，建议采用轻仓操作和严格的仓位管理。这样在极端市场下，即便出现亏损，也不会对总体资金产生过大影响。

  • 止盈与止损策略
    赚够钱提前平仓是控制风险和锁定收益的重要策略，同时需要预设风险边界，一旦市场出现异常反转迹象，及时调整持仓以减少损失。

4. 总结

总体来说，这个策略的思路是合理的——利用VXX长期下行的结构性缺陷，通过买入远期期权捕捉下跌收益，同时利用期权买方风险有限的特点来控制损失。优势在于在正常市场中大概率赚取小额利润，风险仅限于期权成本；但关键挑战在于：

  • 黑天鹅事件可能带来的短期剧烈波动，要求交易者能够耐心持仓，等待波动率回落；
  • 长期持有的时间价值损耗必须谨慎控制；
  • 严格的仓位和风险管理是成功的关键。

如果能在策略执行中严格控制仓位，并有明确的入场、平仓和风险管理规则，这一策略在大部分市场环境下胜率较高、收益稳定，同时小概率亏损风险也是可控的。

mysql json 解析

需求：

  • 从 json 字段 data 中提取满足指定规则的信息，json talbe 尽量只解析一次后复用
  • data 字段的 $.arr[*].xxx 路径是一个数组，每个数组元素有 myid和 name 两个 key
  • 如果 title 字段包含数组中某个元素的 name ，则返回该元素的 id
    • title 字段是一个句子， json 键 name 是一个单词，所以正则查找要加 \b 单词边界
    • title 和 name 的字符集排序规则不一致，匹配时要统一
  • 否则返回数组中第一个元素的 myid
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
DROP FUNCTION IF EXISTS get_myid;
delimiter $$
create function get_myid(p_title varchar(255), p_data json) returns int unsigned
READS SQL DATA
begin
    declare ret int unsigned;

    WITH parsed_data AS (
        select * from
        JSON_TABLE(p_data, '$.arr[*].xxx'
            COLUMNS (
                myid INT PATH '$.myid',
                name VARCHAR(255) PATH '$.name'
            )
        ) jt
    )
    SELECT COALESCE(
        (
            SELECT myid FROM parsed_data
            where p_title COLLATE utf8mb4_0900_ai_ci regexp concat('\\b', REGEXP_REPLACE(name,'[^\\w &]',''),'\\b')
            LIMIT 1
        ),
        (SELECT myid FROM parsed_data LIMIT 1)
    ) INTO ret;

    return ret;
end$$
delimiter ;

select id,myid,get_myid(title, data) myid_by_func from mytable limit 10;

Make Ubuntu packages 90% faster by rebuilding them
https://gist.github.com/jwbee/7e8b27e298de8bbbf8abfa4c232db097

You can take the same source code package that Ubuntu uses to build jq, compile it again, and realize 90% better performance.

  • 编译器用 clang 代替 gcc

  • 编译选项增加 -O3 -flto -DNDEBUG

  • 内存分配器用微软的 mimalloc 替换 glibc

    git clone https://github.com/jqlang/jq.git
    cd jq/
    git submodule update --init

    sudo apt install -y autoconf automake libtool
    autoreconf -i

    sudo apt install clang-18 lld-18
    sudo apt install libmimalloc-dev

    CC=clang-18 LDFLAGS=“-flto -g -Wl,–emit-relocs -Wl,-z,now -Wl,–gc-sections -fuse-ld=lld -lmimalloc” CFLAGS=“-flto -DNDEBUG -fno-omit-frame-pointer -gmlt -march=native -O3 -mno-omit-leaf-frame-pointer -ffunction-sections -fdata-sections -DMIMALLOC=1 -I/usr/local/include” ./configure

    make clean
    make -j$(nproc)

    ldd .libs/jq

THE STARTUP CTO’S HANDBOOK
https://github.com/ZachGoldberg/Startup-CTO-Handbook/blob/main/StartupCTOHandbook.md?ref=xpz

南墙WEB应用防火墙（简称：uuWAF）一款工业级免费、高性能、高扩展，支持AI和语义引擎的Web应用和API安全防护产品。它是有安科技推出的一款全方位网站防护产品，率先实现了流量层、系统层、运行时层3层纵深防御功能。
https://github.com/Safe3/uuWAF/blob/main/README_CN.md

New tools for building agents
https://openai.com/index/new-tools-for-building-agents/?ref=xpz

信息的AI可视化（1）：AI生成动态PPT的步骤分享
https://mp.weixin.qq.com/s/8Yv-_x1xqSon8oRSAmyauA
【教程】一个提示词生成29种排版风格，秒杀80%人水平，附在线免费用网址
https://mp.weixin.qq.com/s/Cz4Xwsa5ZS6tW-H5YdQzSw

https://github.com/junegunn/fzf
sudo apt install fzf
apt show fzf
source /usr/share/doc/fzf/examples/key-bindings.bash

How to Use NotebookLM for Developers
https://clickup.com/blog/how-to-use-notebooklm-for-developers/

向 clickhouse 导入 jsonl 数据

批量导入压缩的 jsonl 数据到 clickhouse，同时动态增加一个字段保存源文件名

for file in /path/to/files/*.jsonl.gz; do
    echo "Importing $file..."
    zcat "$file" | jq --arg myfile "$file" '. + {filename: $myfile}' | clickhouse-client --query="INSERT INTO your_table FORMAT JSONEachRow"
done

nuxt3 app 使用 prisma 在部署后页面报错的问题

现象是 pnpm dev 整个 app 是正常的，但 pnpm build 后再 node server/index.mjs 打开 app 浏览器报错，所有 vue 事件得不到执行。

编译时报错 1

Nuxt Build Error: [commonjs--resolver] Invalid module ".prisma/client/index-browser"

编译时报错 2

".prisma/client/index-browser" is imported by ".prisma/client/index-browser?commonjs-external", but could not be resolved – treating it as an external dependency.

编译时报错 3

Failed to resolve module specifier ".prisma/client/index-browser"

运行时报错

Uncaught TypeError: Error resolving module specifier “.prisma/client/index-browser”. Relative module specifiers must start with “./”, “../” or “/”.

解决方案

nuxt.config.ts 要对 vite 做特殊配置

vite: {
    resolve: {
        alias: {
            '.prisma/client/index-browser': './node_modules/.prisma/client/index-browser.js',
        },
    },
},

prisma/schema.prisma 要对 prisma client 生成做自定义配置

generator client {
    provider      = "prisma-client-js"
    binaryTargets = ["native", "debian-openssl-3.0.x"]
    output = "../node_modules/.prisma/client" // 这行必须加
}

使用 npm 代替 pnpm，此步骤必须，否则其它步骤做了也没用

rm -rf node_modules
npm install
npm run build
node .output/server/index.mjs

服务端部署时要做特殊处理，除了 .output 要复制到服务器，还要在服务器上把 prisma 相关配置部署上去

# prod
mkdir -p /data/www/myapp/app
mkdir -p /data/www/myapp/db

# local
rsync -avzP --delete .output/ prod:/data/www/myapp/app
rsync -avzP ./prisma prod:/data/www/myqpp/db/

# prod
$ cd /data/www/myapp
$ cat env-myqpp.sh
export WECHAT_APP_ID=
export WECHAT_APP_SECRET=
export JWT_SECRET=
export DATABASE_URL="file:/data/www/myapp/db.db"
export RETURN_URL="https://myapp.com/en/"
export PORT=3003
export NUXT_PUBLIC_RETURN_URL="https://myqpp.com/en/"
export NUXT_PUBLIC_WECHAT_APP_ID=
export NUXT_APP_BASE_URL="/en/"

$ cd /data/www/myapp/db
$ cat .env
DATABASE_URL=file:/data/www/myapp/db.db
$ npx prisma migrate deploy
SQLite database db.db created at file:/data/www/english-every-day/db.db
2 migrations found in prisma/migrations

$ cd /data/www/myapp/app
$ source ../env-myapp.sh
$ node server/index.mjs

mysql json 多值索引

-- 建表
CREATE TABLE products (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    tags JSON
);

-- 填充数据
INSERT INTO products (name, tags) VALUES
('Apple', JSON_ARRAY('fruit', 'red', 'sweet')),
('Banana', JSON_ARRAY('fruit', 'yellow', 'sweet')),
('Cucumber', JSON_ARRAY('vegetable', 'green', 'fresh')),
('Tomato', JSON_ARRAY('fruit', 'red', 'fresh'));

-- 创建多值索引
CREATE INDEX idx_tags ON products((CAST(JSON_EXTRACT(tags, '$[*]') AS CHAR(100) ARRAY)));

-- 查询

1. EXPLAIN SELECT * FROM products WHERE 'red' MEMBER OF (tags->>'$[*]');
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | products | NULL       | ALL  | NULL          | NULL | NULL    | NULL |   16 |   100.00 | Using where |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+

2. EXPLAIN SELECT * FROM products WHERE JSON_CONTAINS(tags, JSON_QUOTE('red'));
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | products | NULL       | ALL  | NULL          | NULL | NULL    | NULL |   16 |   100.00 | Using where |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+----------+-------------+

3. EXPLAIN SELECT * FROM products WHERE 'red' MEMBER OF (json_extract(`tags`,_utf8mb4'$[*]'));
+----+-------------+----------+------------+------+---------------+----------+---------+-------+------+----------+-------------+
| id | select_type | table    | partitions | type | possible_keys | key      | key_len | ref   | rows | filtered | Extra       |
+----+-------------+----------+------------+------+---------------+----------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | products | NULL       | ref  | idx_tags      | idx_tags | 403     | const |   36 |   100.00 | Using where |
+----+-------------+----------+------------+------+---------------+----------+---------+-------+------+----------+-------------+

Cloudflare R2 解决CORS跨域问题
https://blog.csdn.net/qq_41301064/article/details/144906864

  • 配置R2 CORS 策略
  • 配置转换规则-修改响应头，(实测可跳过该步骤)
  • 清除缓存(必须)

小文本分类

  • 数据预处理做了删除异常值，填充空值，小写化，标点符号处理，去除停用词（stop words），提取词根 / 词形还原(nltk)，同义词归并，TruncatedSVD降维
  • 向量化器测试了CountVectorizer，TfidfVectorizer，bert 的 SentenceTransformer(‘all-MiniLM-L6-v2’)
  • 模型测试了逻辑回归LogisticRegression，朴素贝叶斯MultinomialNB，微软的LightGBM
  • 模型评估打印了准确率 Accuracy，精确率Precision，召回率 Recall，F1 Score，混淆矩阵 Confusion Matrix，错误样本 misclassified_samples，详细分类报告 classification_report
  • 各模型的参数微调也测了，比如迭代次数，early stop，learning rate等
  • 贝叶斯分类的输入不能有负数，所以 bert 和 svd 降维后的数据不能用贝叶斯训练

LightGBM：处理大规模数据的梯度提升树算法，提升机器学习的速度与精准度
https://mp.weixin.qq.com/s?__biz=MzIwNDY0MjYzOA==&mid=2247515344&idx=1&sn=fe18b7b6f43084253326ed752da4fada&chksm=9670980b575da8694ad97af593c12f5fc43aeea68d0b6953ce3fb65ef38c5f7e1526a9b3a891&scene=27

shell

查看所有 binlog 文件的总大小

find . -name "binlog.*" -type f -exec du -b {} + | awk '{sum += $1} END {print sum}' | numfmt --to=iec
4.3T

iftop

iftop 命令详解及数据解读指南
https://blog.csdn.net/2503_90729443/article/details/146260692

  • 常用命令：sudo iftop -i ens5 -n -N -P -F 1.1.1.1/16
  • 顶部刻度条
    • 作用: 动态显示当前带宽占用比例，刻度值随流量自动调整。
    • 判断: 若刻度条频繁满格，说明带宽接近饱和，需优化或排查高流量来源
    • 流量图形条: 按 b 键可启用/禁用图形化流量条，直观显示带宽占比
  • 中部连接列表，这里是有进出方向的，看箭头，两行算一组来看
    • 源地址:端口 → 目标地址:端口
      • => 表示数据从本地发送到目标地址（发送流量，TX）
      • <= 表示数据从目标地址接收至本地（接收流量，TX）
    • 三个速率列：分别为过去 2秒、10秒、40秒 的平均流量速率。
      • 第一列（2秒）：反映瞬时流量波动，适合捕捉突发传输。
      • 第二列（10秒）：短期趋势，识别短暂高负载。
      • 第三列（40秒）：长期趋势，判断持续占用带宽的连接。
    • 排序规则：默认按 2秒速率 降序排列，按 t 可切换排序依据。
  • 底部统计区
    • cum（Cumulative）：从启动 iftop 到当前的累计流量
    • Peak rate：峰值速率，显示监控期间的最高上传（TX）和下载（RX）速率，用于评估网络最大负载。
    • Rates：不同时间段的平均速率，即2s/10s/40s 速率，与中部连接列表的速率列一致，分别对应三个时间窗口的平均值。
  • 识别高流量连接
    • 瞬时高峰：关注 2秒速率 高的连接，可能是大文件传输或异常流量（如攻击）。
    • 持续占用：若某连接的 40秒速率 长期高位，需检查是否为正常服务（如视频流、备份任务）。
  • 带宽瓶颈分析
    • 刻度条饱和：若顶部刻度条持续满格，且底部 Peak rate 接近物理带宽上限，说明网络拥堵。
    • TX/RX 比例失衡：上传（TX）远高于下载（RX）可能为服务器响应请求（如Web服务）；反之可能是客户端下载数据。
  • 异常流量检测
    • 未知IP或端口：陌生地址的高速率连接可能为恶意软件或未经授权的访问。
    • 单向流量激增：如只有发送（=>）无接收（<=），可能为DDoS攻击或数据泄露。
  • 总结
    • 核心指标：关注 2秒速率（突发流量）与 40秒速率（长期趋势）。
    • 异常判断：陌生IP、非常用端口、单向高流量均为危险信号。
    • 优化建议：结合 nethogs（按进程监控）和 tcpdump（抓包分析）深入诊断。

show engine innodb status

如何查看一个mysql的负载是否过高，只能登录mysql命令行，不能登录mysql所在服务器

SHOW FULL PROCESSLIST;
SHOW GLOBAL STATUS LIKE 'Threads%';
SHOW GLOBAL STATUS LIKE 'Connections';
SHOW GLOBAL STATUS LIKE 'Created_tmp%';
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW ENGINE INNODB STATUS\G
指标 可疑表现
Threads_running 长时间 >10，说明可能执行了太多耗时 SQL
Slow_queries 持续增加，说明 SQL 需要优化
InnoDB 等待锁 有大量 waiting for lock 的事务，表明并发写入冲突严重
临时表 Created_tmp_disk_tables / Created_tmp_tables > 0.3，建议优化 SQL 索引
Max_used_connections 接近 max_connections 数据库可能达到连接极限，出现连接拒绝

解释SHOW ENGINE INNODB STATUS\G的下面这段输出

ROW OPERATIONS
--------------

0 queries inside InnoDB, 0 queries in queue
13 read views open inside InnoDB
Process ID=883, Main thread ID=70396269356368 , state=sleeping
Number of rows inserted 329892693, updated 283825209, deleted 31081, read 16187186053
68.23 inserts/s, 503.62 updates/s, 0.00 deletes/s, 3651.73 reads/s
Number of system rows inserted 344, updated 10388, deleted 247, read 2077404
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.29 reads/s

你提供的 SHOW ENGINE INNODB STATUS\G 输出中的 ROW OPERATIONS 段，是关于 InnoDB 存储引擎在行级别操作的统计信息。我们来逐行解释：

🔹 段落标题

1
2
ROW OPERATIONS
--------------

表示以下内容是关于 InnoDB 的行操作（如读、写、更新、删除）的统计。

🔹 当前并发状态

1
0 queries inside InnoDB, 0 queries in queue

含义：

  • 当前没有 SQL 查询在 InnoDB 引擎内部执行
  • 没有查询在等待队列中

👉 性能上这是好现象，说明当前没有并发瓶颈或阻塞。

🔹 版本快照（MVCC）视图

1
13 read views open inside InnoDB

含义：

  • 当前有 13 个 “read view”（即多版本并发控制 MVCC 快照）

👉 通常是由于有 13 个事务正在运行或使用一致性读。这个数字不是问题，但如果长期较高可能说明有长事务未提交。

🔹 主线程状态

1
Process ID=883, Main thread ID=70396269356368 , state=sleeping

含义：

  • InnoDB 的主后台线程当前处于**sleeping（空闲）**状态。
  • 没有后台任务（如 purge、合并 insert buffer 等）在忙碌。

🔹 行操作的历史累计

1
Number of rows inserted 329892693, updated 283825209, deleted 31081, read 16187186053

含义：自数据库启动以来（或这段时间内）：

  • 插入了 约 3.3 亿 行
  • 更新了 约 2.8 亿 行
  • 删除了 3 万 行
  • 读取了 161 亿 行

👉 行读取数量远远高于更新和插入，是常见情况（如大量 SELECT）。

🔹 行操作速率（单位：每秒）

1
68.23 inserts/s, 503.62 updates/s, 0.00 deletes/s, 3651.73 reads/s

含义：这是 过去一段时间（通常是最近 1 秒） 的操作速率：

  • 每秒插入约 68 行
  • 每秒更新约 504 行
  • 删除基本为 0
  • 每秒读取约 3652 行

👉 说明你的业务是典型的 读多、写中等、删除极少 的负载特征。

🔹 系统级操作（系统表或元数据）

1
Number of system rows inserted 344, updated 10388, deleted 247, read 2077404

和

1
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.29 reads/s

是关于 InnoDB 系统内部表（如事务元数据）的操作。

👉 正常情况下这些数字较小，除非你做大量 DDL 操作。

✅ 总结：负载分析结论

  • 当前 InnoDB 很空闲（0 查询在内部，主线程睡眠）
  • 有 13 个读快照，可能有些事务未及时提交，但不是大问题
  • 读操作非常高（3.6K reads/s），写入也活跃，但不是过载
  • 删除几乎没有，业务可能是累加型的（日志型？）
  • 没有明显的锁争用或资源堵塞

👉 MySQL 当前负载并不高，行操作很健康。

–

英语

如何做到流畅阅读英文资料和听懂国外公开课？ - 魏剑峰的回答 - 知乎
https://www.zhihu.com/question/20364185/answer/68330933

如何做到流畅阅读英文资料和听懂国外公开课？ - Cat Chen的回答 - 知乎
https://www.zhihu.com/question/20364185/answer/14980233

推荐一款听力训练材料：60-Second Science ，它是由 Scientific American（科学美国人）出品的科学趣味英语广播，每条长度1到2分钟不等，内容非常有意，同时，它的风格与托福听力考试非常像。
https://www.scientificamerican.com/podcasts/

mysql 锁等待定位

# 建表 
CREATE DATABASE test_lock;
USE test_lock;

CREATE TABLE account (
    id INT PRIMARY KEY,
    balance INT
) ENGINE=InnoDB;

INSERT INTO account VALUES (1, 100), (2, 200);

# session 1
START TRANSACTION;
UPDATE account SET balance = balance - 10 WHERE id = 1;
-- 不提交，保持锁

# session 2
START TRANSACTION;
UPDATE account SET balance = balance + 10 WHERE id = 1;
-- 会阻塞，等待 Session A 释放锁

# session 3
SELECT *,TIMESTAMPDIFF(SECOND,trx_started, NOW()) seconds FROM information_schema.innodb_trx WHERE trx_state = 'LOCK WAIT'\G


SET GLOBAL innodb_status_output_locks = ON;
SHOW VARIABLES LIKE 'innodb_status_output_locks';

show engine innodb status \G

分析这段输出，谁持有锁，谁等待锁

---TRANSACTION 6808630255, ACTIVE 12 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1128, 1 row lock(s)
MySQL thread id 138, OS thread handle 140139012744960, query id 544252034 localhost debian-sys-maint updating
UPDATE account SET balance = balance + 10 WHERE id = 1
------- TRX HAS BEEN WAITING 12 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1194 page no 4 n bits 72 index PRIMARY of table `test_lock`.`account` trx id 6808630255 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 000195d373ee; asc     s ;;
 2: len 7; hex 01000002541c99; asc     T  ;;
 3: len 4; hex 80000032; asc    2;;

------------------
TABLE LOCK table `test_lock`.`account` trx id 6808630255 lock mode IX
RECORD LOCKS space id 1194 page no 4 n bits 72 index PRIMARY of table `test_lock`.`account` trx id 6808630255 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 000195d373ee; asc     s ;;
 2: len 7; hex 01000002541c99; asc     T  ;;
 3: len 4; hex 80000032; asc    2;;

---TRANSACTION 6808630254, ACTIVE 19 sec
2 lock struct(s), heap size 1128, 1 row lock(s), undo log entries 1
MySQL thread id 140, OS thread handle 140139013801728, query id 544252032 localhost debian-sys-maint
TABLE LOCK table `test_lock`.`account` trx id 6808630254 lock mode IX
RECORD LOCKS space id 1194 page no 4 n bits 72 index PRIMARY of table `test_lock`.`account` trx id 6808630254 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 000195d373ee; asc     s ;;
 2: len 7; hex 01000002541c99; asc     T  ;;
 3: len 4; hex 80000032; asc    2;;

回答

根据你提供的输出，我们可以分析出以下的锁竞争情况：

事务 6808630255（正在等待锁）：

  • 事务状态：ACTIVE 12 sec starting index read，表示事务已执行 12 秒，并开始执行索引读取。

  • 查询：UPDATE account SET balance = balance + 10 WHERE id = 1，这是一个更新操作，目标是更新 account 表中 id = 1 的记录。

  • 锁状态：此事务当前处于等待状态，正在等待锁的授予。

    • 它正等待一个 行锁（RECORD LOCKS），锁定 PRIMARY 索引中的特定记录（heap no 2）。
    • 锁模式：排他锁（X），表示此事务试图独占该记录的访问。
    • 它还持有一个 表锁（TABLE LOCK）在 account 表上，锁模式为 意向排他锁（IX）。

事务 6808630254（持有锁）：

  • 事务状态：ACTIVE 19 sec，表示事务已执行 19 秒。

  • 锁状态：此事务持有一个 表锁（TABLE LOCK）在 account 表上，锁模式为 意向排他锁（IX）。

    • 此事务还持有一个 行锁（RECORD LOCKS），锁定了 PRIMARY 索引中的相同记录（heap no 2），并且锁定模式是 排他锁（X），表示它独占了该记录。

锁等待和持有分析：

  • 事务 6808630255 正在 等待事务 6808630254 释放锁，因为事务 6808630254 已经对 PRIMARY 索引中的相同记录（heap no 2）加上了 排他锁（X）。而事务 6808630255 也希望对该记录加上排他锁（X），因此它在等待。

  • 事务 6808630254 还持有一个 意向排他锁（IX）在 account 表上，这并不会直接阻止其他事务进行读操作，但如果其他事务也希望加排他锁或写入数据，可能会发生冲突。

总结：

  • 事务 6808630254 持有 PRIMARY 索引中的记录锁和表锁，并且正在进行更新操作。
  • 事务 6808630255 正在等待 PRIMARY 索引中的记录锁，因为它希望对该记录进行更新操作，但是 事务 6808630254 已经持有该锁。

在这种情况下，事务 6808630255 必须等待事务 6808630254 释放行锁（或提交/回滚事务）才能继续执行。

mysql 8

select * from performance_schema.setup_instruments WHERE NAME LIKE '%data_lock%';;

-- 启用锁相关监控
UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE '%data_lock%';

-- 启用语句采集器
UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE 'statement/sql/%';

-- 启用语句跟踪
UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME IN (
  'events_statements_current',
  'thread_instrumentation'
);


SELECT
  NOW() AS check_time,

  -- 等待事务信息
  r.ENGINE_TRANSACTION_ID AS waiting_trx_id,
  r.THREAD_ID AS waiting_thread_id,
  r.OBJECT_SCHEMA AS waiting_schema,
  r.OBJECT_NAME AS waiting_table,
  r.INDEX_NAME AS waiting_index,
  r.LOCK_MODE AS waiting_lock_mode,
  r.LOCK_TYPE AS waiting_lock_type,
  r.LOCK_DATA AS waiting_lock_data,
  r.LOCK_STATUS AS waiting_lock_status,

  -- 阻塞事务信息
  b.ENGINE_TRANSACTION_ID AS blocking_trx_id,
  b.THREAD_ID AS blocking_thread_id,
  b.OBJECT_SCHEMA AS blocking_schema,
  b.OBJECT_NAME AS blocking_table,
  b.INDEX_NAME AS blocking_index,
  b.LOCK_MODE AS blocking_lock_mode,
  b.LOCK_TYPE AS blocking_lock_type,
  b.LOCK_DATA AS blocking_lock_data,
  b.LOCK_STATUS AS blocking_lock_status,

  -- 可选：阻塞线程正在执行的 SQL（如果可用）
  es.SQL_TEXT AS blocking_sql

FROM performance_schema.data_lock_waits w
JOIN performance_schema.data_locks r
  ON w.REQUESTING_ENGINE_LOCK_ID = r.ENGINE_LOCK_ID
JOIN performance_schema.data_locks b
  ON w.BLOCKING_ENGINE_LOCK_ID = b.ENGINE_LOCK_ID
LEFT JOIN performance_schema.threads t
  ON b.THREAD_ID = t.THREAD_ID
LEFT JOIN performance_schema.events_statements_current es
  ON t.PROCESSLIST_ID = es.THREAD_ID

ORDER BY r.ENGINE_TRANSACTION_ID\G

日志

https://zhuanlan.zhihu.com/p/572625895
如何实现高性能的日志

  • 批量写入：攒够数据，一次写入
  • 唤醒机制：通知唤醒 notify + 超时唤醒 wait_timeout
  • 锁的粒度：刷新磁盘时，日志接口不会阻塞。这是通过双队列实现的，前台队列实现日志接口，后台队列实现刷新磁盘。
  • 内存分配：移动语义，避免深拷贝；双缓冲，前台后台都设有。