皖月清风的个人博客

InnoDB 按锁粒度分类 表级锁：锁住整张表，粒度最大、开销小、并发低。 行级锁：锁住单行/多行记录，粒度最小、开销大、并发最高。 页级锁：锁住数据页，粒度介于表锁和行锁之间。 最常用：行级锁（InnoDB 默认主打，支撑高并发事务）。 MySQL 慢查询日志默认是关闭（OFF）的，不会自动记录慢 SQL存储过程：把一堆 SQL 语句打包好，提前编译存在 MySQL 服务器里，给它起个名字，以后直接调用名字就能一次性执行完。即数据库的脚本 EFK 架构 三大组件 全称与作用EFK 分别对应 E：Elasticsearch F：Fluentd K：Kibana 各自作用1. Fluentd（采集层 F）负责：收集、过滤、转发日志 从服务器/容器/应用 采集日志 做清洗、过滤、格式化 转发给 Elasticsearch👉 定位：日志搬运工+预处理 2. Elasticsearch（存储检索层 E）负责：存储 + 检索 + 分析日志 接收 Fluentd 发来的日志 分词、索引、持久化存储 提供快速搜索、聚合统计👉 定位：日志数据库+搜索...

在 Vibe Coding（氛围编程）语境下，Harness 不是传统意义上的测试脚手架，而是一套完整的 AI 代码生成约束与验证体系，用来让 AI 写的代码可控、可验证、可长期迭代。 Harness 的四层核心结构（Go 项目通用）1. 环境约束（最基础）定义 AI 能操作的边界，防止乱改项目。 约束类型 具体规则 目录白名单 只允许修改 internal/、api/、tests/ 文件黑名单 禁止碰 go.mod、main.go、配置文件、Dockerfile 依赖约束 只能使用项目已有的依赖，禁止新增未审核依赖 权限约束 AI 无生产环境权限，仅在测试 / 开发环境运行 2. 任务约束（生成前）给 AI 明确的「任务说明书」，而不是模糊需求。 约束类型 具体规则 目标清晰 做什么、不做什么、边界在哪里 验收标准 必须通过哪些测试、lint、覆盖率 技术栈约束 必须用 Gin、GORM、Redis、特定目录结构 代码规范 必须遵循 Go 官方规范、团队 lint 规则、注释规范 3. 验证约束（生成后，最关键）...

MySQL 慢查询什么是慢查询执行时间超过阈值（比如 1 秒）的 SQL，会被记录到慢查询日志里。慢查询是导致接口超时、数据库 CPU 100%、服务卡顿的头号原因。默认 MySQL 慢查询日志是关闭的，你得先打开。 临时开启1234567891011-- 开启慢查询日志SET GLOBAL slow_query_log = 1;-- 设置慢查询阈值：超过 1 秒就算慢查询（根据业务调整）SET GLOBAL long_query_time = 1;-- 日志文件路径SET GLOBAL slow_query_log_file = '/var/lib/mysql/slow.log';-- 记录没有使用索引的 SQL（可选，非常有用）SET GLOBAL log_queries_not_using_indexes = 1; 永久开启（修改 my.cnf/my.ini）[mysqld]slow_query_log = 1slow_query_log_file = /var/lib/mysql/s...

我已经有 EFK（Elasticsearch + Fluentd + Kibana）/ELK 看日志了，查问题也挺方便，为啥还要多搞一套链路追踪？ 为什么需要链路追踪？EFK 是“看文字记录”，链路追踪是“看地图+路线+耗时”。日志能告诉你“发生了什么”，链路追踪能告诉你“请求怎么走的、谁慢了、谁挂了”。 1. EFK 只能看到“点”，链路追踪能看到“整条线”假设用户下单失败，你去 EFK 搜日志： 用 EFK 查问题你只能看到： 订单服务报错了 支付服务也报错了 用户服务好像也有问题 但你完全不知道： 谁先调用谁？ 是谁导致谁挂了？ 是调用链断在哪一步？ 日志是分散的，像一堆散落的纸条。 用链路追踪查问题直接给你一张完整调用路线图：网关 → 订单服务 → 库存服务 → 支付服务 → DB并且标红：支付服务调用超时 瞬间定位根因。 2. EFK 没有“请求串联”能力微服务里，一个请求会穿过：5 个服务 + 3 个数据库 + 2 个缓存 + MQ EFK 里： 订单服务日志：request-id=abc123 支付服务日志：traceId...

EFK速通ELK 是 Elasticsearch + Logstash + Kibana 的缩写，现在主流搭配是 Elasticsearch + Filebeat + Kibana（EFK），Filebeat 更轻量、资源占用更低。 一、3个组件干什么？ Elasticsearch（ES）：核心数据库+搜索引擎，存日志、快速查日志，端口 9200。 Filebeat：轻量日志采集器，装在服务器上读日志文件、发给 ES，端口 5044。 Kibana：可视化面板，网页看日志、做图表、搜数据，端口 5601。 极简流程：Filebeat 采集日志 → Elasticsearch 存储 → Kibana 查看/分析 二、环境准备（Linux/CentOS 7）1. 基础要求 系统：CentOS 7 / Ubuntu（新手推荐 CentOS 7） 内存：至少 2GB（ES 很吃内存） Java：Elasticsearch 8.x 自带 JDK，不用额外装 Java 2. 关闭防火墙/开放端口123456789# 临时关闭防火墙systemctl...

MCPMCP是定义在上下文当中的MCP 把上下文拆成 5 大标准模块（全部在协议里明确定义）： 1. System Context（系统上下文）定义：Agent 的身份、行为规则、Skills 范围MCP 定义：系统提示（System Instruction）可用 Skills 列表（Agent 会什么）约束、权限、安全规则 2. User Context（用户上下文）定义：用户信息、目标、历史、偏好MCP 定义：当前用户请求对话历史（短期记忆）用户长期偏好 / 配置会话状态 3. Tool Context（工具上下文）定义：所有可用 Tools 的元数据 + 调用规范MCP 定义（最核心）：工具名、描述、参数 schema工具权限、可用范围调用格式、返回格式工具状态、执行结果 4. Resource Context（资源上下文）定义：静态数据 / 文档 / 知识MCP 定义：文件、数据库、API 数据RAG 检索结果知识库、配置 5. Session Context（会话上下文）定义：多轮状态、执行流MCP 定义：任务进度中间结果多步骤执行状态 融...

重定向和请求转发重定向是服务器返回 3xx 让浏览器重新访问新 URL（地址栏会改变，需二次请求），而请求转发只在同一服务器内部把同一 request 转给其他资源处理（一次请求，地址栏不变）。 Elasticsearch相关Elasticsearch：擅长“模糊”和“相关性”搜索。例如：搜索“苹果手机”，它不仅能找到包含“苹果”和“手机”的商品，还能通过算法智能地判断出“iPhone”、“iOS设备”的相关性，并按照相关度高低返回结果。这是因为它底层使用了倒排索引 这种神奇的数据结构。 倒排索引（Inverted Index）一句话：把“文档→关键词”反过来，变成“关键词→文档”，用来做快速搜索。 1. 它是什么？正常存储是： 文档1：我喜欢苹果 文档2：苹果很好吃 倒排索引就是反过来： 苹果 → 文档1、文档2 喜欢 → 文档1 好吃 → 文档2 这样搜“苹果”，直接就能拿到所有包含它的文档，不用全文扫一遍。 2. 核心结构一般包含两部分： 词典（Term Dictionary）所有关键词的集合：苹果、喜欢、好吃…… 倒排表（Posting List）每个词对应...

线程池一、什么是线程池？线程池 = 提前创建好的一堆线程 + 任务队列 + 调度器 你可以把它理解成： 一个固定人数的“工人小组”，专门等着处理你丢过来的“任务”。 不用每次来任务都新招工人（创建线程） 任务做完工人不辞退（不销毁线程） 工人闲着就等着，来任务马上干活 任务太多排排队，不会一下子把系统压垮 这就是线程池。 二、为什么要用线程池？（核心作用）如果不用线程池，你每次处理任务都 new Thread()，会有 3 个致命问题： 1. 频繁创建/销毁线程 → 非常耗性能创建线程、销毁线程是重量级操作，比执行普通代码慢得多。线程池让线程复用，避免反复创建销毁。 2. 无限制创建线程 → 系统崩溃如果你来了 1000 个任务，就开 1000 个线程： CPU 疯狂切换 内存爆掉 程序直接卡死 线程池可以限制最大线程数量，保证系统稳定。 3. 线程管理混乱手动创建线程很难统一管理： 怎么控制并发数？ 怎么拒绝过载任务？ 怎么监控任务状态？ 线程池自带管理、监控、拒绝策略、定时任务等功能。 三、线程池的核心好处（总结版） 降低资源消耗：复用...

Mysql存储引擎 主索引（聚簇索引）将数据存储在叶子节点，辅助索引存储指向主键的指针 # 什么是存储过程？ **存储过程（Stored Procedure）** 是**数据库中预先编译好、存储在服务器上的一组 SQL 语句集合**，你可以把它理解成**数据库里的“自定义函数/小程序”**。 它提前把复杂的 SQL 逻辑（增删改查、循环、判断、事务等）写好并保存，需要使用时，直接调用名字就能执行，不用重复写代码。 一、用最简单的比喻理解你要做一道菜： 普通 SQL：每次都把所有食材、步骤写一遍，一步步操作； 存储过程：把完整菜谱提前存在厨房，想吃的时候喊一声菜名，厨师直接按菜谱做好。 二、核心特点 存储在数据库服务器不是写在你的代码里，而是保存在 MySQL、Oracle、SQL Server 等数据库中。 预先编译第一次执行后就编译好了，后续调用速度更快。 可重复调用一次编写，无数次使用，程序、报表、脚本都能直接调用。 支持参数、逻辑判断、循环能实现复杂业务逻辑，不只是简单查询。 减少网络传输不用把一大段 SQL 发给服务器，只发一个调用指令。 三、...

MySQL 锁分类MySQL 锁按锁粒度、锁模式、实现机制、并发思想四大维度划分，主流 InnoDB 引擎下核心锁类型如下： 一、按锁粒度（作用范围）1. 全局锁（Global Lock） 锁定整个数据库实例，所有表只读、不可写 命令：FLUSH TABLES WITH READ LOCK（FTWRL） 场景：全库逻辑备份、主从切换 2. 表级锁（Table Lock） 锁定整张表，粒度大、开销小、并发低 子类型： 表读锁（共享）：LOCK TABLES ... READ 表写锁（排他）：LOCK TABLES ... WRITE 元数据锁（MDL）：保护表结构，DDL/DML 自动加 意向锁（IS/IX）：InnoDB 表级意向，兼容行锁 引擎：MyISAM、InnoDB（无索引时退化为表锁） 3. 行级锁（Row Lock） 锁定单行，粒度最小、并发最高，InnoDB 核心 依赖索引实现，无索引会全表加锁 4. 页级锁（Page Lock） 锁定 16KB 数据页，仅 BDB 引擎（已淘汰） 二、按锁模式（读写兼容性）1. 共享锁（S 锁 ...