Ethan 发布的文章 - CorePlayers

MySQL 性能调优实战：索引优化、SQL 调优与分库分表策略 数据库性能问题是后端开发中最常见的瓶颈。然而，很多开发者的"优化"就是在字段上加个索引——然后发现还是慢。本文将系统梳理 MySQL 性能调优的三个核心维度：索引优化、SQL 调优和分库分表，并介绍 Druid 监控工具的使用。索引优化的本质：数据结构的选择B+Tree 为什么是 MySQL 的首选？B+Tree 的所有数据都存在叶子节点，非叶子节点只存索引——这让单次磁盘 I/O 能检索更多索引键。在 16KB 的 InnoDB 页中，假设主键是 BIGINT（8字节）+ 指针（6字节），一个非叶子节点大约能存 16KB / 14B ≈ 1170 个索引键。三层 B+Tree（根→中间→叶子）约能索引 1170 × 1170 × 16 ≈ 两千万行。这意味着绝大多数 OLTP 查询只需 1~3 次磁盘 I/O。最左前缀原则：面试必问CREATE INDEX idx_a_b_c ON users(a, b, c); -- 走索引（匹配最左前缀） SELECT * FROM users WHERE a = 1; SELECT * FROM users WHERE a = 1 AND b = 2; -- 不走索引（跳过了 a） SELECT * FROM users WHERE b = 2; SELECT * FROM users WHERE c = 3; -- 部分走索引（a 走索引，c 不走） SELECT * FROM users WHERE a = 1 AND c = 3;索引失效的常见场景-- 1. 函数操作（索引列参与计算） SELECT * FROM orders WHERE DATE(create_time) = '2025-01-01'; -- 失效！ -- 改为：WHERE create_time >= '2025-01-01' AND create_time < '2025-01-02'; -- 2. 隐式类型转换 SELECT * FROM users WHERE phone = 13800138000; -- phone 是 VARCHAR，失效！ -- 3. LIKE 前置模糊 SELECT * FROM articles WHERE title LIKE '%MySQL%'; -- 完全失效 -- 4. OR 条件不全有索引 SELECT * FROM users WHERE name = 'ABC' OR age = 25; -- age 没有索引覆盖索引：最优雅的性能优化CREATE INDEX idx_name_age ON users(name, age); SELECT name, age FROM users WHERE name = 'ABC'; -- 不需要回表！SQL 执行计划分析（EXPLAIN 必看项）EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 'paid'; -- 关键指标 -- type: const > eq_ref > ref > range > index > ALL（绝对不能出现 ALL） -- key: 实际使用的索引 -- rows: 扫描行数（越小越好） -- Extra: Using filesort / Using temporary（出现就说明需要优化）慢查询分析：找到瓶颈-- 开启慢查询日志 SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; -- 用 mysqldumpslow 分析 mysqldumpslow -s t -t 10 /var/log/mysql/slow.logDruid SQL 监控// Spring Boot 集成 Druid spring: datasource: druid: stat-view-servlet: enabled: true url-pattern: /druid/* login-username: admin login-password: admin filter: stat: enabled: true slow-sql-millis: 1000 log-slow-sql: true通过 /druid/index.html 可视化查看：SQL 执行次数、耗时分布、连接池状态、慢查询列表。分库分表策略垂直分库：按业务拆分用户库（user_db）、订单库（order_db）、商品库（product_db），各库独立部署、独立扩容。水平分表：ShardingSphere-JDBC 配置# sharding.yml rules: - !SHARDING tables: t_order: actualDataNodes: ds0.t_order_$-> databaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: db_inline tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: order_inline shardingAlgorithms: db_inline: type: INLINE props: algorithm-expression: ds$-> order_inline: type: INLINE props: algorithm-expression: t_order_$->总结MySQL 优化有一个优先级：SQL 优化 > 索引优化 > 架构优化。大多数性能问题的根源在于糟糕的 SQL 和缺失的索引，而不是"数据库配置参数不够好"。Druid 监控是你发现这些问题的眼睛，而分库分表是最后的底牌——在此之前，请先确保 SQL 和索引已经做到最好。

多模态 RAG：图像检索增强生成的完整实践指南 传统 RAG（检索增强生成）主要处理文本数据，但在实际应用中，大量知识以图像、图表、PDF 扫描件等形式存在。多模态 RAG 将 RAG 的能力从文本扩展到图像，使得 AI 应用可以理解和检索视觉信息。本文将提供完整的技术实现方案。多模态 RAG 的架构设计一个典型的多模态 RAG 系统包含以下组件：1. 多模态嵌入模型：CLIP（Contrastive Language-Image Pre-training）是目前最主流的多模态嵌入模型。它可以将图像和文本映射到同一个向量空间，使得文本查询可以直接检索相关图像。OpenAI 的 CLIP ViT-L/14 模型在多项基准测试中表现最优，而开源替代方案如 Chinese-CLIP 在中文场景中更具优势。2. 多模态文档解析：PDF、PPT 等文档中的图文混合内容需要专门的解析器。Unstructured 库和 LlamaParse 是目前最成熟的方案，它们可以将复杂文档拆解为"文本块 + 关联图像块"的结构化片段。3. 多向量存储：支持向量搜索的数据库（如 Milvus、Weaviate）需要同时存储文本嵌入和图像嵌入，并维护它们之间的关联映射。完整流程1. 文档解析：将 PDF 中的文本和图像分别提取，记录它们在页面中的位置关系。2. 嵌入生成：文本块使用 text-embedding-3-large 生成嵌入，图像使用 CLIP 生成嵌入。3. 存储：将两种嵌入及元数据存入向量数据库，同时建立"文本块 ↔ 图像块"的映射表。4. 检索：用户查询时，使用相同的嵌入模型将查询转为向量，同时搜索文本向量和图像向量。5. 生成：将检索到的文本和图像 URL/描述一起传入多模态 LLM（如 GPT-4o），生成集成答案。

Vue 3 Composition API 实战：从 Options API 到 Composables 思维转型 Vue 3 的 Composition API 不仅仅是一种新的 API 风格，它代表了一种全新的代码组织思维——从"按选项类型组织"转向"按逻辑关注点组织"。本文将从一个真实项目的重构案例出发，深入讲解 Composition API 的实战技巧。Options API 的痛点：逻辑碎片化考虑一个典型的搜索组件，使用 Options API 编写时，一个功能（搜索）的逻辑会散落在 data、watch、methods、mounted、beforeUnmount 等多个选项中。当组件变得复杂时，在数百行代码中追踪一个功能的完整逻辑变得极其困难。Composition API 的解决方案：按功能聚合同样的搜索功能，用 Composition API 重写后，所有搜索相关的逻辑——状态、副作用、清理——都被封装在一个 composable 函数中。这就是 Composable（组合函数） 的核心思想。function useSearch() \n finally \n }\n\n function debounceSearch(val) , 300);\n }\n\n watch(keyword, debounceSearch);\n onBeforeUnmount(() => clearTimeout(timer));\n\n return ;\n}ref vs reactive：何时用哪个？// ref：适用于基本类型和需要整体替换的场景\nconst count = ref(0);\nconst user = ref();\ncount.value++; // 需要 .value\nuser.value = ; // 可以整体替换\n\n// reactive：适用于复杂对象，不需要 .value\nconst state = reactive(, settings: });\nstate.user.name = '李四'; // 直接访问，无 .value\n\n// reactive 的限制：不能整体替换\nlet state = reactive();\nstate = reactive(); // 破坏了响应式引用\n// 用 ref 包装对象避免此问题实战建议：对于组件内部状态，优先使用 ref（更灵活，类型推断更好）；对于包含多个相关属性的配置对象，使用 reactive。Composable 设计原则1. 单一职责一个 Composable 只做一件事。如果 useUser() 既管理用户认证又管理用户偏好设置，应该拆分为 useAuth() 和 usePreferences()。2. 可配置而非硬编码function useSearch( = ) 3. 清理副作用function useEventListener(target, event, handler) 实战案例：可复用的数据获取 Composablefunction useFetch(url) catch (e) \n finally \n }\n\n if (isRef(url)) ); }\n else \n\n return ;\n}从 Options API 迁移的渐进策略不需要一次性重写整个项目：新组件直接用 Composition API，提取可复用的 Composable 从现有 mixin 开始转化，复杂组件（超过 300 行）逐个重构，利用 setup 语法糖进一步简化代码。Options API 不会消失——对于简单组件，它仍然是非常好的选择。Composition API 的价值主要体现在复杂组件的逻辑组织和跨组件的逻辑复用。

Go 1.24 泛型新特性与生产实战 Go 1.24 在 2025 年初发布，泛型特性迎来了第二次重大迭代。从 Go 1.18 的泛型初版到如今的 1.24，泛型已经从"实验性功能"进化为了"生产级基础设施"。本文将从实战角度解析 Go 1.24 泛型的最佳实践。Go 1.24 泛型新特性1. 类型推断增强：Go 1.24 显著改进了泛型函数的类型推断能力，大部分场景下不再需要显式指定类型参数。// Go 1.21 需要显式指定类型 result := Map[int, string](nums, strconv.Itoa) // Go 1.24 自动推断 result := Map(nums, strconv.Itoa)2. Range over func：迭代器模式正式进入标准库，使得泛型集合可以无缝使用 for-range 循环。3. 标准库泛型化：slices、maps、cmp 等包新增了大量泛型工具函数，大幅减少重复代码。实战：构建类型安全的泛型仓库层在典型的三层架构中，每个实体的 CRUD 操作通常高度相似。使用 Go 1.24 泛型可以消除这些重复：type Repository[T any, ID comparable] interface 通过泛型接口和实现，原本需要为每个实体（User、Order、Product 等）重复编写的 200+ 行仓储代码可以压缩为一个通用实现。性能考量Go 的泛型在编译时进行单态化（monomorphization），这意味着每个具体类型会生成独立的代码，不存在运行时开销。但这也意味着编译时间和二进制大小会有所增加。在我们的测试中，泛型化后的仓库层代码量减少了 60%，而二进制大小仅增加了 3.2%，编译时间增加 8%。

CSS Container Queries 实战：告别 Media Queries 的局限 CSS Container Queries 是近年来最受期待的前端新特性之一，在 2025 年主流浏览器全面支持后，它彻底改变了响应式设计的范式。与传统的 Media Queries 基于视口宽度不同，Container Queries 允许组件根据其父容器的大小来调整样式，真正实现了"组件级响应式"。为什么需要 Container Queries？传统 Media Queries 的最大问题是：组件的样式依赖于整个页面的视口宽度，而不是组件自身的上下文。当一个卡片组件被放在主内容区（宽 800px）和侧边栏（宽 300px）时，Media Queries 无法区分这两种场景，因为它们共享同一个视口。Container Queries 解决了这个问题——组件的样式只与包裹它的容器相关。核心语法首先，需要将父元素声明为一个查询容器：.card-wrapper 然后使用 @container 规则编写响应式样式：@container card (min-width: 400px) } @container card (max-width: 399px) }实战场景1. 自适应仪表盘布局：不同尺寸的卡片可以独立响应，无需全局断点。2. 可复用组件库：组件在任何上下文中都能正确显示，极大提高可复用性。3. 多栏布局优化：结合 CSS Grid，实现真正的内容感知布局。性能考量过度使用 Container Queries 可能导致布局抖动。建议仅在确实需要组件级响应的地方使用，避免在深层嵌套中创建过多查询容器。使用 Chrome DevTools 的 Container Queries 面板可以直观地调试容器断点。