在 AI 编程助手的演进历程中，一个核心痛点始终存在：“金鱼记忆”。早期模型如 ChatGPT，在每次新对话中都仿佛“失忆”，开发者不得不反复重申项目背景、编码规范和特定需求，效率极低。

Claude Code 通过其革命性的 多层记忆系统，彻底解决了这一问题。它不再只是一个代码生成器，而是能跨会话、跨目录、甚至跨平台理解并记住你工作上下文的智能协作者。本文将深入解析这套系统，并通过一个完整的 Flutter 跨平台开发案例，手把手教你如何构建属于自己的高效记忆体系。

一、为什么需要多层记忆？从“金鱼”到“专家”

想象一下这个场景：

你在 lib/ 目录下用 Dart 写 Flutter 逻辑，需要遵循函数式编程和 Provider 状态管理；但当你进入 android/ 目录修改原生 Kotlin 代码时，又必须遵守 Android 的 minSdkVersion 和 strings.xml 规范。

如果 AI 助手只有一套全局记忆，它就无法在这两种截然不同的上下文中无缝切换。这就是多层记忆的价值所在——让 AI 在正确的地点，加载正确的知识。

Claude Code 提供三种记忆位置，每种都有不同用途：

其中， CLAUDE.md 文件是 Claude Code 自动读取的记忆文件，类似于 Cursor 中 rules 规则文件，但比它要更强大，它可以为 Claude 提供更多项目相关的上下文信息，如：

• 常用的 bash 命令
• 核心文件和工具函数
• 代码风格指南
• 测试说明
• 代码库规范
• 开发环境设置
• 更多希望 Claude 记住的信息等等

当 Claude Code 启动时，以上所有记忆文件会自动加载到运行环境中。

可以在多个位置放置 CLAUDE.md 文件，Claude Code 会递归读取这些文件，从当前工作目录开始，向上递归到根目录，读取找到的任何 CLAUDE.md 文件。

Claude Code 的四层记忆架构

Claude Code 的记忆系统采用分层设计，优先级从高到低依次为：

1. 目录级记忆 (./components/CLAUDE.md)：最精细的控制，适用于特定模块（如 React 组件库、Android 原生模块）。
2. 项目级记忆 (./CLAUDE.md)：最常用层级，包含整个项目的架构、技术栈、测试命令等核心信息。
3. 个人全局记忆 (~/.claude/CLAUDE.md)：你的个人编码偏好，适用于所有项目。
4. 企业级记忆 (/Library/.../CLAUDE.md)：团队统一的安全策略和 CI/CD 流程（由管理员维护）。

关键原则：越具体，优先级越高。当 Claude 在 android/ 目录工作时，它会自动加载 项目根目录/CLAUDE.md + android/CLAUDE.md，而忽略 ios/ 目录下的规则。

图：Claude Code 的四层记忆加载策略。当处理 Button.tsx 文件时，系统只会加载与之相关的记忆文件，确保上下文精准且高效。

二、核心载体：CLAUDE.md 文件详解

CLAUDE.md 是 Claude Code 记忆系统的基石。它是一个纯文本 Markdown 文件，格式自由，但内容至关重要。以下是你可以写入的关键信息：

• 代码风格指南：缩进、模块语法、命名规范。
• 常用命令：npm run test:unit, flutter build。
• 核心文件路径：日志工具、配置文件位置。
• Git 工作流：分支命名、提交信息格式。
• 开发环境：Node.js/Python 版本、必需工具。
• 避坑指南：已知问题、性能陷阱、安全警告。

实战技巧：动态管理记忆

• # 符号快速记录：在聊天中随时输入 # 使用 TypeScript strict mode，Claude 会提示你将其保存到 CLAUDE.md 中。
• /memory 查看上下文：随时检查当前加载了哪些记忆文件。
• @ 模块化导入：避免文件臃肿，用 @docs/testing.md 引用外部详细文档。

三、实战案例：为 Flutter 跨平台项目构建记忆系统

让我们以一个典型的 Flutter 项目为例，演示如何搭建一个多层记忆系统。

项目结构

1
2
3
4
5

my_flutter_app/
├── android/          # Android 原生代码
├── ios/              # iOS 原生代码
├── lib/              # Dart 核心逻辑
└── CLAUDE.md         # 项目级记忆

第一步：初始化项目记忆

在项目根目录运行 /init，Claude 会自动分析代码库，生成一个基础的 CLAUDE.md。

1
2
3
4
5
6
7
8
9
10
11
12
13

# my_flutter_app 项目指南

## 架构
- 状态管理：所有新功能都使用 **Provider** 包。
- 文件结构：按功能分组，放在 `lib/features/` 下。

## 编码风格
- 遵循 "Effective Dart" 风格指南。
- 所有 widget 必须放在单独的文件中。

## 资源
- 图片资源路径：`assets/images/`
- 新增资源必须在 `pubspec.yaml` 中声明。

第二步：添加平台特定规则

1. Android 平台 (android/CLAUDE.md)

1
2
3
4
5

# Android 平台规范

- `minSdkVersion` 必须是 **21**。
- 所有用户可见字符串必须放在 `res/values/strings.xml`。
- 添加新权限需在 `AndroidManifest.xml` 中声明。

2. iOS 平台 (ios/CLAUDE.md)

1
2
3
4
5

# iOS 平台规范

- 部署目标版本：**iOS 12.0**。
- 新的隐私权限需在 `Info.plist` 中添加用途描述。
- 依赖管理：使用 **CocoaPods**。

第三步：验证记忆加载

• 在项目根目录输入 /memory，你会看到加载了 项目级 + 个人级 记忆。
• 进入 android/ 目录再输入 /memory，输出会额外包含 android/CLAUDE.md 的内容。

图：在 android 子目录下，Claude 自动加载了平台特定的记忆，使其能精准地处理原生代码。

第四步：沉淀可复用的工作流

假设你刚完成一个“获取电池电量”的平台通道（Platform Channel）功能，涉及 Dart、Kotlin、Swift 三端代码。你可以使用 /compact 命令将其提炼为标准操作流程（SOP）。

1

/compact 将刚才实现“获取设备电池电量”功能的完整流程总结成一个标准的平台通道 (Platform Channel)实现指南。

Claude 会生成一份结构化摘要。你可以将其保存为 docs/workflows/platform-channel-guide.md，并在主 CLAUDE.md 中引用：

1
2

# 工作流
- 创建新平台通道的指南：@docs/workflows/platform-channel-guide.md

现在，任何团队成员在需要创建类似功能时，只需一句指令，Claude 就能基于这份权威指南生成高质量代码。

四、高级技巧与最佳实践

1. 主动压缩上下文：不要等到 token 用尽。在对话达到 70% 时主动使用 /compact，清理噪音，聚焦核心。
2. 成本控制：对于复杂规划，使用 Opus 模型；对于日常编码和测试，切换到更快更便宜的 Sonnet 或 Haiku。
3. 安全护栏：在 .claude/settings.json 中设置 deny 规则，如 Read(./.env)，防止敏感信息泄露。
4. 团队共享：将 项目级 CLAUDE.md 提交到 Git 仓库，使其成为团队的“活文档”和知识库。

总结

Claude Code 的多层记忆系统，本质上是将 人、项目、智能体 三者协同的工程方法论。它通过 CLAUDE.md 文件，将模糊的口头约定转化为 AI 可执行的精确指令。

当你精心构建起这套记忆体系后，Claude Code 就不再是那个需要你反复解释的“新手”，而是一个真正懂你的项目、懂你的风格、懂你的流程的资深开发搭档。它能显著减少沟通成本，提升代码一致性，并将你的开发体验从“反复试错”升级为“高效协作”。

行动建议：立即在你的下一个项目中创建 CLAUDE.md 文件，从记录一条简单的编码规范开始。你会发现，一个拥有“好记性”的 AI，才是你通往高效开发的终极秘密武器。

参考:

https://aicoding.csdn.net/68b38299080e555a88dfba38.html#devmenu2

https://tianpan.co/zh/blog/2025-08-21-claude-code-tips

https://blog.csdn.net/yangshangwei/article/details/153482628

1. 打开你下载的CC Switch软件，你会看到如下图的初始界面

2. 在分组条中，将分组选择至“Claude”

3. 在供应商分组中，选择如图的“DeepSeek”

4. 创建API令牌，在 DeepSeek中创建 Claude 分组的令牌，点击复制按钮，复制ApiKey到剪切板

5. 下拉模态框，找到“API Key”配置项，填入你刚才复制的ApiKey，再点击右下角“添加”按钮

6. 添加成功后，在主界面会看到我们配置的分组，在右侧点击“启用”按钮，显示“使用中”，则配置完成

7. 在终端运行 claude，看到对话界面并能正常回复即表示配置完成

[!CAUTION]

先要充值使用

[!IMPORTANT]

Codex、Gemini、OpenCode配置同理！

Claude Code / Codex / Gemini CLI 全方位辅助工具

更新日志 | 下载地址

从供应商切换器到 AI CLI 一体化管理平台

统一管理 Claude Code、Codex 与 Gemini CLI 的供应商配置、MCP 服务器、Skills 扩展和系统提示词。

使用 CC-Switch，您可以：

• ✅ 一键切换 API 配置 - 在多个 API 提供商之间快速切换
• ✅ 可视化配置管理 - 通过图形界面轻松管理所有配置
• ✅ 内置 PackyAPI 模板 - 预设了 PackyAPI 的配置模板
• ✅ MCP 服务器管理 - 管理 Model Context Protocol 服务器
• ✅ 系统托盘快捷操作 - 通过托盘菜单快速切换

温馨提示

CC-Switch 已经内置了 PackyAPI 的快捷配置模板，无需手动编辑配置文件！

软件下载

Windows

1. 点击下载链接→传送门←，进入CC-Switch的Github Release页面
2. 鼠标滚动到最下方选择适合自己版本的安装包，windows系统推荐下载普通msi后缀的安装包进行安装

3. 安装后运行CC-Switch主程序，界面如下。

MacOS

• MacOS安装推荐使用HomeBrew
• 开启终端后，分别运行以下命令：

1
2
3
4
5

# 添加 tap 源
brew tap farion1231/ccswitch

# 安装 CC-Switch
brew install --cask cc-switch

• 安装完成后，在“启动台”或“应用程序”文件夹中找到 CC-Switch 并启动。

Linux

[!CAUTION]

以下命令中的文件名包含占位符版本号 x.x.x，请访问GitHub Releases 页面查看最新版本，并替换为实际的版本号和完整文件名

Debian/Ubuntu 系统：

1
2
3
4
5

# 下载 .deb 包
wget https://github.com/farion1231/cc-switch/releases/latest/download/cc-switch_x.x.x_amd64.deb

# 安装
sudo dpkg -i cc-switch_x.x.x_amd64.deb

环境检查

注意

请你最好进行此步的环境检查步骤！！！
如果你有经验，能确认你的Nodejs环境以及cc、codex、gemini的cli安装没问题，配置目录也都存在，可以忽略这一步，直接进入后续的CC Switch配置

Claude 在国内用，API 其实不是很友好，除了 Claude 官方的模型，我能用其他 AI 模型吗？

本章节会详细教你如何配置多个国内主流 AI 模型的 API，让 Claude Code 支持：

进入对应控制台后，注册/登录 → 完成实名认证 → 创建 API Key 即可开始调用。

API 管理工具

平台一多，配置起来就麻烦，我们可以使用第三方工具 CC Switch 可以帮我们轻松管理这几个热门工具的 API 配置：https://github.com/farion1231/cc-switch/，Windows / macOS / Linux 全支持。

CC Switch 是一个 Claude Code / Codex / Gemini CLI 的全方位辅助工具。

CC Switch 可以帮我们轻松管理这几个热门工具的 API 配置，就好比给你的开发工具箱来了个智能整理助手，所有工具的配置都能在它这有序管理。

各平台安装包下载地址：https://github.com/farion1231/cc-switch/releases。

具体的操作设置参考文章：https://mp.weixin.qq.com/s/pa9Gpim7jVXsUtEM8JwnSg

如果你不闲麻烦，可以参照下文，自行配置。

DeepSeek 接入 Claude Code

环境变量中配置

安装 Claude Code 后，我们在终端中设置以下环境变量：

1
2
3
4
5
6

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=${DEEPSEEK_API_KEY} # 这里记得设置你申请的 API key
export API_TIMEOUT_MS=600000
export ANTHROPIC_MODEL=deepseek-chat
export ANTHROPIC_SMALL_FAST_MODEL=deepseek-chat
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

参数说明：

• API_TIMEOUT_MS=600000：设置 10 分钟超时，防止输出过长触发客户端超时
• ANTHROPIC_MODEL：指定使用 deepseek-chat 模型
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1：禁用非必要流量

然后进入项目目录，执行 claude 命令，即可开始使用了。

1
2

cd my-project
claude

启动 Claude Code 后，指定使用 DeepSeek：

1

claude --model deepseek-chat

或在交互模式中切换：

1

> /model deepseek-chat

输入 /model 可以查看支持的模型：

参考文档：https://api-docs.deepseek.com/zh-cn/guides/anthropic_api

阿里百炼接入 Claude Code

阿里云百炼的通义千问系列模型支持 Anthropic API 兼容接口，通过修改以下参数，即可在 Claude Code 中调用通义千问系列模型。

• ANTHROPIC_API_KEY（或 ANTHROPIC_AUTH_TOKEN）：替换为百炼 API Key，申请地址：https://bailian.console.aliyun.com/cn-beijing/?tab=model#/api-key。
• ANTHROPIC_BASE_URL：替换为百炼的兼容端点地址 https://dashscope.aliyuncs.com/apps/anthropic。
• 模型名称：替换为百炼支持的模型名称（例如 qwen3-max、qwen3-coder-plus等）

macOS：

1
2
3

# 用百炼 API KEY 替换 YOUR_DASHSCOPE_API_KEY
echo 'export ANTHROPIC_BASE_URL="https://dashscope.aliyuncs.com/apps/anthropic"' >> ~/.zshrc
echo 'export ANTHROPIC_API_KEY="YOUR_DASHSCOPE_API_KEY"' >> ~/.zshrc

配置完成后需要重新加载配置文件：

1

source ~/.zshrc

Windows：

在 CMD 中运行以下命令，设置环境变量：

1
2
3

# 用百炼 API Key 替换 YOUR_DASHSCOPE_API_KEY
setx ANTHROPIC_API_KEY "YOUR_DASHSCOPE_API_KEY"
setx ANTHROPIC_BASE_URL "https://dashscope.aliyuncs.com/apps/anthropic"

在 PowerShell 中运行以下命令，设置环境变量：

1
2
3

# 用百炼 API Key 替换 YOUR_DASHSCOPE_API_KEY
[Environment]::SetEnvironmentVariable("ANTHROPIC_API_KEY", "YOUR_DASHSCOPE_API_KEY", [EnvironmentVariableTarget]::User)
[Environment]::SetEnvironmentVariable("ANTHROPIC_BASE_URL", "https://dashscope.aliyuncs.com/apps/anthropic", [EnvironmentVariableTarget]::User)

在 Claude Code 中接入通义千问系列模型

对话期间，执行 /model <模型名称> 命令切换模型。

1

/model qwen3-coder-plus

也可以在项目根目录创建 .claude/settings.json 文件中，并写入模型配置信息永久配置。

1
2
3
4
5
6

{
  "env": {
    "ANTHROPIC_MODEL": "qwen3-coder-plus",
    "ANTHROPIC_SMALL_FAST_MODEL": "qwen-flash"
  }
}

启动 Claude，可以看到配置信息：

智谱大模型接入 Claude Code

这部分我们使用 ~/.claude/settings.json 文件来配置大模型，开始前需要到官方平台获取 API key：GLM Coding Plan。

编辑或新增 Claude Code 配置文件 ~/.claude/settings.json ，新增或修改里面的 env 字段

1
2
3
4
5
6
7
8
9

# 注意替换里面的your_zhipu_api_key 为您上一步获取到的 API Key
{
    "env": {
        "ANTHROPIC_AUTH_TOKEN": "your_zhipu_api_key",
        "ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/anthropic",
        "API_TIMEOUT_MS": "3000000",
        "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1
    }
}

运行 claude 启动 Claude Code，输入 /status 确认模型状态：

如果不是可以输入 /config 来切换模型。

VS Code 安装 Claude Code

如果不喜欢使用 Claude Code 的命令行模型，我们可以在 VS Code 编辑器中安装 Claude Code。

打开 VS Code，进入扩展市场，搜索 Claude Code 安装：

安装完成后，点击右上角 Claude Code 图标，即可进入 Claude Code 页面：

这样有账号的可以使用 /login 登录：

也可以在对话框输入 /config 进入设置，勾选 Disable Login Prompt 配置来关闭登录页面:

在正式安装之前，我们先了解一下 Claude Code 可以怎么用。

三种使用方式对比：

我的建议:

• 如果你是完全新手，先用 Web 端 https://claude.ai/ 试试手感
• 如果你想真正用于开发，直接学 CLI(命令行)
• 如果你已经熟练使用，再考虑编辑器集成

目前 Claude Code 的桌面版也发布了，下载地址：https://claude.com/download。

本教程将以 CLI 使用方式为主，因为它最稳定、最通用，也最接近 Claude Code 的设计初衷。

安装 Claude Code CLI(命令行工具)

前置准备

在安装之前,你需要确保:

1、你有一个 Claude 账号，当然现在国内很多厂家（DeepSeek/Minimax/GLM）已经适配，后文会介绍怎么切换。

• 访问 claude.ai 注册账号
• 如果你已经在用 Claude 聊天，那就已经有账号了

你的电脑有命令行工具

• Mac / Linux:打开 Terminal(终端)
• Windows:打开 PowerShell 或者安装 WSL

使用官方脚本安装

macOS, Linux, WSL:

1

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

1

irm https://claude.ai/install.ps1 | iex

Windows CMD:

1

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

安装完成后,验证一下:

1

claude --version

如果显示版本号，说明安装成功!

使用 npm 安装

你的电脑需要安装了 Node.js，在命令行输入：

1

node --version

如果显示版本号(比如 v18.17.0)，说明已安装。如果没有，去 nodejs.org 下载安装。

安装 Claude Code

打开命令行，输入以下命令:

1

npm install -g @anthropic-ai/claude-code

等待安装完成(可能需要几分钟)。

安装完成后，验证一下:

1

claude --version

如果显示版本号,说明安装成功!

Claude Code 是 Anthropic 推出的面向开发者的 AI 编程协作工具，与在聊天窗口里写几段代码不同，Claude Code 的核心目标是理解你的整个项目，并参与到真实的编码、修改和重构过程中。

Claude Code 不是一个代码生成器，而是一个能读项目、懂上下文、遵守约束的 AI 编程搭档。

简单说:Claude Code 是 Claude 的命令行版本,专门为编程场景设计。

它不是网页里的聊天框，而是直接在你的终端(Terminal)里运行,可以:

• 读取你整个项目的代码
• 理解文件之间的关系
• 直接修改代码文件
• 执行你的指令并给出建议

从能力角度看，Claude Code 主要具备三点特征：

• 上下文感知：不仅理解单个文件，而是理解整个项目结构
• 工程化导向：关注可维护性、规范、测试，而不是一次性代码
• 可定制行为：通过 Skills（技能包）让 AI 遵守你的规则

打个比方:

• Claude(网页版) 就像一个顾问，你把代码截图或复制给他，他给你建议，但你得自己动手改。
• Claude Code 就像一个坐在你旁边的搭档，他能看到你的整个项目，帮你改代码，甚至帮你写测试、重构函数。

Claude Code 能做什么?

Claude Code 的核心能力可以归纳为这几点:

1、代码理解与解释

我们可以问它:

• 这个函数是干什么的?
• 为什么这里会报错?
• 这段代码的性能瓶颈在哪?

它会结合你的项目上下文给出解释。

2、多文件上下文分析

不同于简单的代码补全工具,Claude Code 能理解:

• 这个函数在哪些地方被调用了
• 这个模块依赖了哪些其他文件
• 整个项目的架构是怎样的

3、工程级代码修改

我们可以说:

• 把所有用 var 的地方改成 let
• 把这个函数拆成三个小函数
• 给所有接口加上错误处理

它会帮你实际修改代码,而不只是给建议。

4、通过 Skills(技能包)扩展能力

Skills 是 Claude Code 最强大的地方——我们可以教它你的编码习惯和团队规范，让它按我们的方式工作。

比如:

• 我们团队要求所有函数都加注释
• API 响应必须符合特定格式
• 测试用例要覆盖边界情况

你可以把这些要求写成 Skills，Claude Code 就会自动遵守。

Claude Code 不能做什么?

Claude Code 不擅长的事情：

• 不能替你做技术决策的最终判断
• 不能保证生成代码 100% 无 Bug
• 不能理解你没有明确说明的业务语义
• 不适合在你完全不理解的情况下全自动接管项目

一个成熟的使用心态是：让 Claude Code 提供高质量候选方案，而不是绝对正确答案。

Claude Code 的核心价值

Claude Code 的核心理念：协作，而不是替代

Claude Code 并不是在追求把开发者踢出局，它的设计理念非常明确：

• 人负责：目标、约束、判断、审美
• AI 负责：执行、分析、对比、重复劳动

对编程新手: 降低学习门槛

如果你是新手，最痛苦的可能是:

• 看不懂别人的代码
• 不知道为什么报错
• 不知道好代码长什么样

Claude Code 可以:

• 用人话解释代码:这段代码的意思是先检查用户是否登录，如果没登录就跳转到登录页
• 帮你 Debug: 这里报错是因为变量名拼错了，应该是 username 不是 usrname
• 教你写更好的代码: 这个函数太长了，可以拆成三个小函数，分别负责验证、处理、返回

对独立开发者: 提升开发效率

如果你是独立开发者，你可能:

• 一个人负责前后端
• 没人帮你 Code Review
• 需要快速试错和迭代

Claude Code 可以:

• 帮你快速理解第三方库的用法
• 自动生成测试用例
• 帮你重构混乱的代码

对团队: 统一规范,降低协作成本

如果你在团队工作，你可能遇到:

• 每个人代码风格不一样
• 新人上手慢,老是问重复问题
• Code Review 花时间

Claude Code 可以:

• 通过 Skills 统一团队规范(所有人用同一套规则)
• 帮新人快速理解项目
• 在提交前自动检查代码质量

Claude Code 适合哪些人?

我建议以下几类人可以尝试 Claude Code:

编程新手

• 想学编程但总是卡在看不懂代码
• 需要一个随时解答问题的老师

独立开发者 / 创业者

• 一个人做项目,需要快速试错
• 想把时间花在核心功能上,不想在琐碎问题上卡住

后端 / 前端 / 全栈工程师

• 想提升开发效率
• 想学习更好的代码写法
• 需要快速理解复杂项目

技术负责人 / 架构师

• 想用 AI 辅助团队规范落地
• 想降低新人培养成本

不适合的场景

• 你完全不想学编程，只想输入需求自动出项目(AI 还做不到)
• 你的工作涉及高度敏感代码，不能使用外部 AI 服务

Claude Code 和其他 AI 编程工具有什么区别?

你可能还听说过 ChatGPT、Cursor、GitHub Copilot，它们和 Claude Code 有什么不同?

Claude Code vs ChatGPT

Claude Code vs Cursor / Copilot

简单总结:

• Copilot/Cursor:边写边补全，像智能输入法
• Claude Code:对话式协作，像高级搭档
• ChatGPT:通用助手，像顾问

Claude Code 的优势:

• 对整个项目的理解能力更强
• 可以通过 Skills 定制行为
• 更适合理解旧代码大规模重构等场景

Claude Code 的局限:

• 不如 Copilot 那样无感(需要主动调用)
• 学习曲线稍高

@SpringBootConfiguration

SpringBootConfiguration 是 SpringBoot 项目的配置注解，这也是一个组合注解，SpringBootConfiguration 注解可以用 java 代码的形式实现 Spring 中 xml 配置文件配置的效果，并会将当前类内声明的一个或多个以 @Bean 注解标记的方法的实例纳入到 spring 容器中，并且实例名就是方法名。

SpringBootConfiguration 可以作为 Spring 标准中 @Configuration 注解的替代。SpringBoot 项目中推荐使用@SpringBootConfiguration 替代 @Configuration。

@Scope

@Scope注解主要作用是调节Ioc容器中的作用域，在Spring IoC容器中主要有以下五种作用域：基本作用域：singleton(单例)、prototype(多例);Web 作用域(reqeust、session、globalsession)，自定义作用域。

@Scope注解是springIoc容器中的一个作用域，在 Spring IoC 容器中具有以下几种作用域：基本作用域singleton（单例）、prototype(多例)，Web 作用域（reqeust、session、globalsession），自定义作用域

• singleton单例模式(默认):全局有且仅有一个实例
• prototype原型模式:每次获取Bean的时候会有一个新的实例
• request: request表示该针对每一次HTTP请求都会产生一个新的bean，同时该bean仅在当前HTTP request内有效
• session :session作用域表示该针对每一次HTTP请求都会产生一个新的bean，同时该bean仅在当前HTTP session内有效
• global session : global session作用域类似于标准的HTTP Session作用域，不过它仅仅在基于portlet的web应用中才有意义

直接使用字符串容易出问题,spring有默认的参数:

• ConfigurableBeanFactory.SCOPE_PROTOTYPE，即“prototype”
• ConfigurableBeanFactory.SCOPE_SINGLETON，即“singleton”
• WebApplicationContext.SCOPE_REQUEST，即“request”
• WebApplicationContext.SCOPE_SESSION，即“session”

二、常用注解

@SpringBootApplication

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@Configuration
@EnableAutoConfiguration
@ComponentScan
public @interface SpringBootApplication {

/**
 * Exclude specific auto-configuration classes such that they will never be applied.
 * @return the classes to exclude
 */
Class<?>[] exclude() default {};

}

定义在main方法入口类处，用于启动sping boot应用项目

@EnableAutoConfiguration

让spring boot根据类路径中的jar包依赖当前项目进行自动配置

在src/main/resources的META-INF/spring.factories

1
2
3
4
5

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration

若有多个自动配置，用“，”隔开

@ImportResource

加载xml配置，一般是放在启动main类上

1
2
3

@ImportResource("classpath*:/spring/*.xml")  单个

@ImportResource({"classpath*:/spring/1.xml","classpath*:/spring/2.xml"})   多个

@Value

application.properties定义属性，直接使用@Value注入即可

1
2
3
4

public class A{
 @Value("${push.start:0}")    如果缺失，默认值为0
     private Long  id;
}

@ConfigurationProperties

可以新建一个properties文件，ConfigurationProperties的属性prefix指定properties的配置的前缀，通过location指定properties文件的位置

1
2
3
4
5
6

@ConfigurationProperties(prefix="person")
public class PersonProperties {

private String name ;
private int age;
}

@EnableConfigurationProperties

用 @EnableConfigurationProperties注解使 @ConfigurationProperties生效，并从IOC容器中获取bean。

https://blog.csdn.net/u010502101/article/details/78758330

@RestController

组合@Controller和@ResponseBody，当你开发一个和页面交互数据的控制时，比如bbs-web的api接口需要此注解

@RequestMapping

用来映射web请求(访问路径和参数)、处理类和方法，可以注解在类或方法上。注解在方法上的路径会继承注解在类上的路径。

produces属性: 定制返回的response的媒体类型和字符集，或需返回值是json对象

1

@RequestMapping(value="/api2/copper",produces="application/json;charset=UTF-8",method = RequestMethod.POST)

@RequestParam

获取request请求的参数值

1
2
3
4
5

public List<CopperVO> getOpList(HttpServletRequest request,
                                   @RequestParam(value = "pageIndex", required = false) Integer pageIndex,
                                   @RequestParam(value = "pageSize", required = false) Integer pageSize) {

 }

@ResponseBody

支持将返回值放在response体内，而不是返回一个页面。比如Ajax接口，可以用此注解返回数据而不是页面。此注解可以放置在返回值前或方法前。

1
2
3
4
5
6
7
8
9
10

另一个玩法，可以不用@ResponseBody。
继承FastJsonHttpMessageConverter类并对writeInternal方法扩展，在spring响应结果时，再次拦截、加工结果
// stringResult: json返回结果
//HttpOutputMessage outputMessage

 byte[] payload = stringResult.getBytes();
 outputMessage.getHeaders().setContentType(META_TYPE);
 outputMessage.getHeaders().setContentLength(payload.length);
 outputMessage.getBody().write(payload);
 outputMessage.getBody().flush();

@Bean

@Bean(name=”bean的名字”,initMethod=”初始化时调用方法名字”,destroyMethod=”close”)

定义在方法上，在容器内初始化一个bean实例类。

1
2
3
4
5

@Bean(destroyMethod="close")
@ConditionalOnMissingBean
public PersonService registryService() {
return new PersonService();
}

@Service

用于标注业务层组件

@Controller

用于标注控制层组件(如struts中的action)

@Repository

用于标注数据访问组件，即DAO组件

@Component

泛指组件，当组件不好归类的时候，我们可以使用这个注解进行标注。

@PostConstruct

spring容器初始化时，要执行该方法

1
2
3

@PostConstruct  
public void init() {   
}

@PathVariable

用来获得请求url中的动态参数

1
2
3
4
5
6
7
8
9
10
11
12
13

@Controller  
public class TestController {  

     @RequestMapping(value="/user/{userId}/roles/{roleId}",method = RequestMethod.GET)  
     public String getLogin(@PathVariable("userId") String userId,  
         @PathVariable("roleId") String roleId){
           
         System.out.println("User Id : " + userId);  
         System.out.println("Role Id : " + roleId);  
         return "hello";  
     
     }  
}

@ComponentScan

注解会告知Spring扫描指定的包来初始化Spring

1

@ComponentScan(basePackages = "com.bbs.xx")

@EnableZuulProxy

路由网关的主要目的是为了让所有的微服务对外只有一个接口，我们只需访问一个网关地址，即可由网关将所有的请求代理到不同的服务中。Spring Cloud是通过Zuul来实现的，支持自动路由映射到在Eureka Server上注册的服务。Spring Cloud提供了注解@EnableZuulProxy来启用路由代理。

@Autowired

在默认情况下使用 @Autowired 注释进行自动注入时，Spring 容器中匹配的候选 Bean 数目必须有且仅有一个。当找不到一个匹配的 Bean 时，Spring 容器将抛出 BeanCreationException 异常，并指出必须至少拥有一个匹配的 Bean。

当不能确定 Spring 容器中一定拥有某个类的 Bean 时，可以在需要自动注入该类 Bean 的地方可以使用 @Autowired(required = false)，这等于告诉 Spring: 在找不到匹配 Bean 时也不报错

@Autowired注解注入map、list与@Qualifier在新窗口打开

@Configuration

1
2
3
4
5
6
7
8
9
10
11
12
13

@Configuration("name")//表示这是一个配置信息类,可以给这个配置类也起一个名称
@ComponentScan("spring4")//类似于xml中的<context:component-scan base-package="spring4"/>
public class Config {

    @Autowired//自动注入，如果容器中有多个符合的bean时，需要进一步明确
    @Qualifier("compent")//进一步指明注入bean名称为compent的bean
    private Compent compent;

    @Bean//类似于xml中的<bean id="newbean" class="spring4.Compent"/>
    public Compent newbean(){
        return new Compent();
    }   
}

@Import

导入Config1配置类里实例化的bean

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Configuration
public class CDConfig {

    @Bean   // 将SgtPeppers注册为 SpringContext中的bean
    public CompactDisc compactDisc() {
        return new CompactDisc();  // CompactDisc类型的
    }
}

@Configuration
@Import(CDConfig.class)  //导入CDConfig的配置
public class CDPlayerConfig {

    @Bean(name = "cDPlayer")
    public CDPlayer cdPlayer(CompactDisc compactDisc) {  
         // 这里会注入CompactDisc类型的bean
         // 这里注入的这个bean是CDConfig.class中的CompactDisc类型的那个bean
        return new CDPlayer(compactDisc);
    }
}

@Order

@Order(1)，值越小优先级超高，越先运行

三、条件注解

如果注解指定的条件成立，则触发指定行为，条件注解列表:

@ConditionalOnRepositoryType (org.springframework.boot.autoconfigure.data)
@ConditionalOnDefaultWebSecurity (org.springframework.boot.autoconfigure.security)
@ConditionalOnSingleCandidate (org.springframework.boot.autoconfigure.condition)
@ConditionalOnWebApplication (org.springframework.boot.autoconfigure.condition)
@ConditionalOnWarDeployment (org.springframework.boot.autoconfigure.condition)
@ConditionalOnJndi (org.springframework.boot.autoconfigure.condition)
@ConditionalOnResource (org.springframework.boot.autoconfigure.condition)
@ConditionalOnExpression (org.springframework.boot.autoconfigure.condition)
@ConditionalOnClass (org.springframework.boot.autoconfigure.condition)
@ConditionalOnEnabledResourceChain (org.springframework.boot.autoconfigure.web)
@ConditionalOnMissingClass (org.springframework.boot.autoconfigure.condition)
@ConditionalOnNotWebApplication (org.springframework.boot.autoconfigure.condition)
@ConditionalOnProperty (org.springframework.boot.autoconfigure.condition)
@ConditionalOnCloudPlatform (org.springframework.boot.autoconfigure.condition)
@ConditionalOnBean (org.springframework.boot.autoconfigure.condition)
@ConditionalOnMissingBean (org.springframework.boot.autoconfigure.condition)
@ConditionalOnMissingFilterBean (org.springframework.boot.autoconfigure.web.servlet)
@Profile (org.springframework.context.annotation)
@ConditionalOnInitializedRestarter (org.springframework.boot.devtools.restart)
@ConditionalOnGraphQlSchema (org.springframework.boot.autoconfigure.graphql)
@ConditionalOnJava (org.springframework.boot.autoconfigure.condition)

@ConditionalOnMissingClass

如果类路径中不存在这个类，则触发指定行为

@ConditionalOnBean

如果容器中存在这个Bean（组件），则触发指定行为，@ConditionalOnBean（value=组件类型，name=组件名字）：判断容器中是否有这个类型的组件，并且名字是指定的值

@ConditionalOnMissingBean

如果容器中不存在这个Bean（组件），则触发指定行为

场景：

如果存在FastsqlException这个类，给容器中放一个Cat组件，名cat01，

否则，就给容器中放一个Dog组件，名dog01

如果系统中有dog01这个组件，就给容器中放一个 User组件，名zhangsan

否则，就放一个User，名叫lisi

@ConditionalOnProperty

这个注解能够控制某个 @Configuration 是否生效。具体操作是通过其两个属性name以及havingValue来实现的，其中name用来从application.properties中读取某个属性值，如果该值为空，则返回false;如果值不为空，则将该值与havingValue指定的值进行比较，如果一样则返回true;否则返回false。如果返回值为false，则该configuration不生效；为true则生效。

https://blog.csdn.net/dalangzhonghangxing/article/details/78420057

@ConditionalOnClass

如果类路径中存在这个类，则触发指定行为；

该注解的参数对应的类必须存在，否则不解析该注解修饰的配置类；

1
2
3
4
5
6
7
8
9
10
11
12

@Configuration
@ConditionalOnClass({Gson.class})
public class GsonAutoConfiguration {
    public GsonAutoConfiguration() {
    }

    @Bean
    @ConditionalOnMissingBean
    public Gson gson() {
        return new Gson();
    }
}

@ConditionalOnMisssingClass

1

@ConditionalOnMisssingClass({ApplicationManager.class})

如果存在它修饰的类的bean，则不需要再创建这个bean；

@ConditionOnMissingBean

1

@ConditionOnMissingBean(name = "example")

表示如果name为“example”的bean存在，该注解修饰的代码块不执行。

@ConditionalOnExpression

1
2
3
4
5
6
7
8

@Configuration
@ConditionalOnExpression("${enabled:false}")
public class BigpipeConfiguration {
    @Bean
    public OrderMessageMonitor orderMessageMonitor(ConfigContext configContext) {
        return new OrderMessageMonitor(configContext);
    }
}

开关为true的时候才实例化bean

四、属性绑定

@ConfigurationProperties

声明组件的属性和配置文件哪些前缀开始项进行绑定

@EnableConfigurationProperties

快速注册注解：

• 场景： SpringBoot默认只扫描自己主程序所在的包。如果导入第三方包，即使组件上标注了 @Component、@ConfigurationProperties 注解，也没用。因为组件都扫描不进来，此时使用这个注解就可以快速进行属性绑定并把组件注册进容器

这个一点倒是很重要，SpringBoot默认扫描当前项目主程序包及其子包，再加上自动配置类，那么属性类是不会扫描到的，此时就算加上@Component注解也是没有任何用处，所以一般是在属性类上面使用 @ConfigurationProperties注解，而在相应的自动配置类上面使用@EnableConfigurationProperties注解，从而让属性类绑定生效

• 将容器中任意组件（Bean）的属性值和配置文件的配置项的值进行绑定

  • 1、给容器中注册组件（@Component、@Bean)

  • 2、使用 @ConfigurationProperties 声明组件和配置文件的哪些配置项进行绑定

五、缓存注解

@EnableCaching

开启缓存注解的支持

@Cacheable

@Cacheable 注解表示方法的结果应该被缓存起来，下次调用该方法时，如果参数和之前相同，则返回缓存结果。

1
2
3
4
5
6
7

@Service
public class MyService {
    @Cacheable("greetingCache")
    public String greeting(String name) {
        return "Hello, " + name + "!";
    }
}

@CachePut

@CachePut 注解表示方法的结果应该被缓存起来，下次调用该方法时，不会返回缓存结果，而是重新计算结果并缓存起来。

1
2
3
4
5
6
7

@Service
public class MyService {
    @CachePut("greetingCache")
    public String greeting(String name) {
        return "Hello, " + name + "!";
    }
}

@CacheEvict

@CacheEvict 注解表示方法执行后从缓存中删除指定项。

1
2
3
4
5
6

@Service
public class MyService {
    @CacheEvict("greetingCache")
    public void clearGreetingCache() {
    }
}

@CacheConfig

@CacheConfig是结合@Cacheable使用的来设置过期时间的

@Caching

@Caching 注解可以在一个方法或者类上同时指定多个Spring Cache相关的注解。
其拥有三个属性：cacheable、put 和 evict，分别用于指定@Cacheable、@CachePut 和 @CacheEvict。对于一个数据变动，更新多个缓存的场景，可以通过 @Caching 来实现：

1
2
3
4

@Caching(cacheable = @Cacheable(cacheNames = "caching", key = "#age"), evict = @CacheEvict(cacheNames = "t4", key = "#age"))
public String caching(int age) {
    return "caching: " + age + "-->" + UUID.randomUUID().toString();
}

参考：

https://www.cnblogs.com/ziyue7575/p/c925cfe466df01c1d352f37da8823946.html

https://pdai.tech/md/spring/springboot/springboot-x-hello-anno.html

解决

1. 管理员身份运行Windows PowerShell
2. 执行：get-ExecutionPolicy，显示Restricted，表示状态是禁止的;

1
2

Restricted禁止的
RemoteSigned允许的

3. 执行：set-ExecutionPolicy

​ 3.1 会提示输入参数：RemoteSigned，然后回车

​ 3.2 或者直接输入 set-executionpolicy remotesigned 回车

这样就能使用了；

​ 举个例子，一个消息M发送到了消息中间件，消息投递到了消费程序A，A接受到了消息，然后进行消费，但在消费到一半的时候程序重启了，这时候这个消息并没有标记为消费成功，这个消息还会继续投递给这个消费者，直到其消费成功了，消息中间件才会停止投递。

​ 然而这种可靠的特性导致，消息可能被多次地投递。举个例子，还是刚刚这个例子，程序A接受到这个消息M并完成消费逻辑之后，正想通知消息中间件“我已经消费成功了”的时候，程序就重启了，那么对于消息中间件来说，这个消息并没有成功消费过，所以他还会继续投递。这时候对于应用程序A来说，看起来就是这个消息明明消费成功了，但是消息中间件还在重复投递。

​ 这在RockectMQ的场景来看，就是同一个messageId的消息重复投递下来了。

​ 基于消息的投递可靠（消息不丢）是优先级更高的，所以消息不重的任务就会转移到应用程序自我实现，这也是为什么RocketMQ的文档里强调的，消费逻辑需要自我实现幂等。背后的逻辑其实就是：不丢和不重是矛盾的（在分布式场景下），但消息重复是有解决方案的，而消息丢失是很麻烦的。

简单的消息去重解决方案

例如：假设我们业务的消息消费逻辑是：插入某张订单表的数据，然后更新库存：

1

insert into t_order values ..... update t_inv set count = count-1 where good_id = 'good123';

要实现消息的幂等，我们可能会采取这样的方案：

1

select * from t_order where order_no = 'order123' if(order  != null) {     return ;//消息重复，直接返回 }

这对于很多情况下，的确能起到不错的效果，但是在并发场景下，还是会有问题。

并发重复消息

​ 假设这个消费的所有代码加起来需要1秒，有重复的消息在这1秒内（假设100毫秒）内到达（例如生产者快速重发，Broker重启等），那么很可能，上面去重代码里面会发现，数据依然是空的（因为上一条消息还没消费完，还没成功更新订单状态），

​ 那么就会穿透掉检查的挡板，最后导致重复的消息消费逻辑进入到非幂等安全的业务代码中，从而引发重复消费的问题（如主键冲突抛出异常、库存被重复扣减而没释放等）

并发去重的解决方案之一

要解决上面并发场景下的消息幂等问题，一个可取的方案是开启事务把select 改成 select for update语句，把记录进行锁定。

1

select * from t_order where order_no = 'THIS_ORDER_NO' for update  //开启事务 if(order.status != null) {    return ;//消息重复，直接返回 }

​ 但这样消费的逻辑会因为引入了事务包裹而导致整个消息消费可能变长，并发度下降。

当然还有其他更高级的解决方案，例如更新订单状态采取乐观锁，更新失败则消息重新消费之类的。但这需要针对具体业务场景做更复杂和细致的代码开发、库表设计，不在本文讨论的范围。

​ 但无论是select for update， 还是乐观锁这种解决方案，实际上都是基于业务表本身做去重，这无疑增加了业务开发的复杂度， 一个业务系统里面很大部分的请求处理都是依赖MQ的，如果每个消费逻辑本身都需要基于业务本身而做去重/幂等的开发的话，这是繁琐的工作量。本文希望探索出一个通用的消息幂等处理的方法，从而抽象出一定的工具类用以适用各个业务场景。

Exactly Once

​ 在消息中间件里，有一个投递语义的概念，而这个语义里有一个叫”Exactly Once”，即消息肯定会被成功消费，并且只会被消费一次。以下是阿里云里对Exactly Once的解释：

Exactly-Once 是指发送到消息系统的消息只能被消费端处理且仅处理一次，即使生产端重试消息发送导致某消息重复投递，该消息在消费端也只被消费一次。

在我们业务消息幂等处理的领域内，可以认为业务消息的代码肯定会被执行，并且只被执行一次，那么我们可以认为是Exactly Once。

但这在分布式的场景下想找一个通用的方案几乎是不可能的。不过如果是针对基于数据库事务的消费逻辑，实际上是可行的。

基于关系数据库事务插入消息表

假设我们业务的消息消费逻辑是：更新MySQL数据库的某张订单表的状态：

1

update t_order set status = 'SUCCESS' where order_no= 'order123';

​ 要实现Exaclty Once即这个消息只被消费一次（并且肯定要保证能消费一次），我们可以这样做：在这个数据库中增加一个消息消费记录表，把消息插入到这个表，并且把原来的订单更新和这个插入的动作放到同一个事务中一起提交，就能保证消息只会被消费一遍了。

1. 开启事务
2. 插入消息表（处理好主键冲突的问题）
3. 更新订单表（原消费逻辑）
4. 提交事务

说明：

1. 这时候如果消息消费成功并且事务提交了，那么消息表就插入成功了，这时候就算RocketMQ还没有收到消费位点的更新再次投递，也会插入消息失败而视为已经消费过，后续就直接更新消费位点了。这保证我们消费代码只会执行一次。
2. 如果事务提交之前服务挂了（例如重启），对于本地事务并没有执行所以订单没有更新，消息表也没插入成功；而对于RocketMQ服务端来说，消费位点也没更新，所以消息还会继续投递下来，投递下来发现这个消息插入消息表也是成功的，所以可以继续消费。这保证了消息不丢失。

​ 事实上，阿里云ONS的EXACTLY-ONCE语义的实现上，就是类似这个方案基于数据库的事务特性实现的。更多详情可参考：https://help.aliyun.com/document_detail/102777.html

基于这种方式，的确这是有能力拓展到不同的应用场景，因为他的实现方案与具体业务本身无关——而是依赖一个消息表。

但是这里有它的局限性

1. 消息的消费逻辑必须是依赖于关系型数据库事务。如果消费的消费过程中还涉及其他数据的修改，例如Redis这种不支持事务特性的数据源，则这些数据是不可回滚的。
2. 数据库的数据必须是在一个库，跨库无法解决

注：业务上，消息表的设计不应该以消息ID作为标识，而应该以业务的业务主键作为标识更为合理，以应对生产者的重发。阿里云上的消息去重只是RocketMQ的messageId，在生产者因为某些原因手动重发（例如上游针对一个交易重复请求了）的场景下起不到去重/幂等的效果（因消息id不同）。

更复杂的业务场景

​ 如上所述，这种方式Exactly Once语义的实现，实际上有很多局限性，这种局限性使得这个方案基本不具备广泛应用的价值。并且由于基于事务，可能导致锁表时间过长等性能问题。

例如我们以一个比较常见的一个订单申请的消息来举例，可能有以下几步（以下统称为步骤X）：

1. 检查库存（RPC）
2. 锁库存（RPC）
3. 开启事务，插入订单表（MySQL）
4. 调用某些其他下游服务（RPC）
5. 更新订单状态
6. commit 事务（MySQL）

​ 这种情况下，我们如果采取消息表+本地事务的实现方式，消息消费过程中很多子过程是不支持回滚的，也就是说就算我们加了事务，实际上这背后的操作并不是原子性的。怎么说呢，就是说有可能第一条小在经历了第二步锁库存的时候，服务重启了，这时候实际上库存是已经在另外的服务里被锁定了，这并不能被回滚。当然消息还会再次投递下来，要保证消息能至少消费一遍，换句话说，锁库存的这个RPC接口本身依旧要支持“幂等”。

​ 再者，如果在这个比较耗时的长链条场景下加入事务的包裹，将大大的降低系统的并发。所以通常情况下，我们处理这种场景的消息去重的方法还是会使用一开始说的业务自己实现去重逻辑的方式，如前面加select for update，或者使用乐观锁。

​ 那我们有没有方法抽取出一个公共的解决方案，能兼顾去重、通用、高性能呢？

拆解消息执行过程

其中一个思路是把上面的几步，拆解成几个不同的子消息，例如：

1. 库存系统消费A：检查库存并做锁库存，发送消息B给订单服务
2. 订单系统消费消息B：插入订单表（MySQL），发送消息C给自己（下游系统）消费
3. 下游系统消费消息C：处理部分逻辑，发送消息D给订单系统
4. 订单系统消费消息D：更新订单状态

注：上述步骤需要保证本地事务和消息是一个事务的（至少是最终一致性的），这其中涉及到分布式事务消息相关的话题，不在本文论述。

可以看到这样的处理方法会使得每一步的操作都比较原子，而原子则意味着是小事务，小事务则意味着使用消息表+事务的方案显得可行。

然而，这太复杂了！这把一个本来连续的代码逻辑割裂成多个系统多次消息交互！那还不如业务代码层面上加锁实现呢。

更通用的解决方案

上面消息表+本地事务的方案之所以有其局限性和并发的短板，究其根本是因为它依赖于关系型数据库的事务，且必须要把事务包裹于整个消息消费的环节。

如果我们能不依赖事务而实现消息的去重，那么方案就能推广到更复杂的场景例如：RPC、跨库等。

例如，我们依旧使用消息表，但是不依赖事务，而是针对消息表增加消费状态，是否可以解决问题呢？

基于消息幂等表的非事务方案

​ 以上是去事务化后的消息幂等方案的流程，可以看到，此方案是无事务的，而是针对消息表本身做了状态的区分：消费中、消费完成。只有消费完成的消息才会被幂等处理掉。而对于已有消费中的消息，后面重复的消息会触发延迟消费（在RocketMQ的场景下即发送到RETRY TOPIC），之所以触发延迟消费是为了控制并发场景下，第二条消息在第一条消息没完成的过程中，去控制消息不丢（如果直接幂等，那么会丢失消息（同一个消息id的话），因为上一条消息如果没有消费完成的时候，第二条消息你已经告诉broker成功了，那么第一条消息这时候失败broker也不会重新投递了）

上面的流程不再细说，后文有github源码的地址，读者可以参考源码的实现，这里我们回头看看我们一开始想解决的问题是否解决了：

1. 消息已经消费成功了，第二条消息将被直接幂等处理掉（消费成功）。
2. 并发场景下的消息，依旧能满足不会出现消息重复，即穿透幂等挡板的问题。
3. 支持上游业务生产者重发的业务重复的消息幂等问题。

​ 关于第一个问题已经很明显已经解决了，在此就不讨论了。

​ 关于第二个问题是如何解决的？主要是依靠插入消息表的这个动作做控制的，假设我们用MySQL作为消息表的存储媒介（设置消息的唯一ID为主键），那么插入的动作只有一条消息会成功，后面的消息插入会由于主键冲突而失败，走向延迟消费的分支，然后后面延迟消费的时候就会变成上面第一个场景的问题。

​ 关于第三个问题，只要我们设计去重的消息键让其支持业务的主键（例如订单号、请求流水号等），而不仅仅是messageId即可。所以也不是问题。

此方案是否有消息丢失的风险？

​ 如果细心的读者可能会发现这里实际上是有逻辑漏洞的，问题出在上面聊到的个三问题中的第2个问题（并发场景），在并发场景下我们依赖于消息状态是做并发控制使得第2条消息重复的消息会不断延迟消费（重试）。但如果这时候第1条消息也由于一些异常原因（例如机器重启了、外部异常导致消费失败）没有成功消费成功呢？也就是说这时候延迟消费实际上每次下来看到的都是消费中的状态，最后消费就会被视为消费失败而被投递到死信Topic中（RocketMQ默认可以重复消费16次）。

​ 有这种顾虑是正确的！对于此，我们解决的方法是，插入的消息表必须要带一个最长消费过期时间，例如10分钟，意思是如果一个消息处于消费中超过10分钟，就需要从消息表中删除（需要程序自行实现）。所以最后这个消息的流程会是这样的：

更灵活的消息表存储媒介

我们这个方案实际上没有事务的，只需要一个存储的中心媒介，那么自然我们可以选择更灵活的存储媒介，例如Redis。使用Redis有两个好处：

1. 性能上损耗更低
2. 上面我们讲到的超时时间可以直接利用Redis本身的ttl实现

当然Redis存储的数据可靠性、一致性等方面是不如MySQL的，需要用户自己取舍。

源码：RocketMQDedupListener

以上方案针对RocketMQ的Java实现已经开源放到Github中，具体的使用文档可以参考https://github.com/Jaskey/RocketMQDedupListener ，

以下仅贴一个Readme中利用Redis去重的使用样例，用以意业务中如果使用此工具加入消息去重幂等的是多么简单：

1

//利用Redis做幂等表        DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("TEST-APP1");        consumer.subscribe("TEST-TOPIC", "*");         String appName = consumer.getConsumerGroup();// 大部分情况下可直接使用consumer group名        StringRedisTemplate stringRedisTemplate = null;// 这里省略获取StringRedisTemplate的过程        DedupConfig dedupConfig = DedupConfig.enableDedupConsumeConfig(appName, stringRedisTemplate);        DedupConcurrentListener messageListener = new SampleListener(dedupConfig);         consumer.registerMessageListener(messageListener);        consumer.start();

​ 以上代码大部分是原始RocketMQ的必须代码，唯一需要修改的仅仅是创建一个DedupConcurrentListener示例，在这个示例中指明你的消费逻辑和去重的业务键（默认是messageId）。

更多使用详情请参考Github上的说明。

这种实现是否一劳永逸？

​ 实现到这里，似乎方案挺完美的，所有的消息都能快速的接入去重，且与具体业务实现也完全解耦。那么这样是否就完美的完成去重的所有任务呢？

很可惜，其实不是的。原因很简单：因为要保证消息至少被成功消费一遍，那么消息就有机会消费到一半的时候失败触发消息重试的可能。还是以上面的订单流程X：

1. 检查库存（RPC）
2. 锁库存（RPC）
3. 开启事务，插入订单表（MySQL）
4. 调用某些其他下游服务（RPC）
5. 更新订单状态
6. commit 事务（MySQL）

当消息消费到步骤3的时候，我们假设MySQL异常导致失败了，触发消息重试。因为在重试前我们会删除幂等表的记录，所以消息重试的时候就会重新进入消费代码，那么步骤1和步骤2就会重新再执行一遍。如果步骤2本身不是幂等的，那么这个业务消息消费依旧没有做好完整的幂等处理。

本实现方式的价值？

​ 那么既然这个并不能完整的完成消息幂等，还有什么价值呢？价值可就大了！虽然这不是解决消息幂等的银弹（事实上，软件工程领域里基本没有银弹），但是他能以便捷的手段解决：

1.各种由于Broker、负载均衡等原因导致的消息重投递的重复问题

2.各种上游生产者导致的业务级别消息重复问题

3.重复消息并发消费的控制窗口问题，就算重复，重复也不可能同一时间进入消费逻辑

一些其他的消息去重的建议

​ 也就是说，使用这个方法能保证正常的消费逻辑场景下（无异常，无异常退出），消息的幂等工作全部都能解决，无论是业务重复，还是rocketmq特性带来的重复。

事实上，这已经能解决99%的消息重复问题了，毕竟异常的场景肯定是少数的。那么如果希望异常场景下也能处理好幂等的问题，可以做以下工作降低问题率：

1. 消息消费失败做好回滚处理。如果消息消费失败本身是带回滚机制的，那么消息重试自然就没有副作用了。
2. 消费者做好优雅退出处理。这是为了尽可能避免消息消费到一半程序退出导致的消息重试。
3. 一些无法做到幂等的操作，至少要做到终止消费并告警。例如锁库存的操作，如果统一的业务流水锁成功了一次库存，再触发锁库存，如果做不到幂等的处理，至少要做到消息消费触发异常（例如主键冲突导致消费异常等）
4. 在#3做好的前提下，做好消息的消费监控，发现消息重试不断失败的时候，手动做好#1的回滚，使得下次重试消费成功。

消费完后的消息去哪里了？

消息的存储是一直存在于CommitLog中的。而由于CommitLog是以文件为单位（而非消息）存在的，CommitLog的设计是只允许顺序写的，且每个消息大小不定长，所以这决定了消息文件几乎不可能按照消息为单位删除（否则性能会极具下降，逻辑也非常复杂）。所以消息被消费了，消息所占据的物理空间并不会立刻被回收。

但消息既然一直没有删除，那RocketMQ怎么知道应该投递过的消息就不再投递？——答案是客户端自身维护——客户端拉取完消息之后，在响应体中，broker会返回下一次应该拉取的位置，PushConsumer通过这一个位置，更新自己下一次的pull请求。这样就保证了正常情况下，消息只会被投递一次。

什么时候清理物理消息文件？

那消息文件到底删不删，什么时候删？

消息存储在CommitLog之后，的确是会被清理的，但是这个清理只会在以下任一条件成立才会批量删除消息文件（CommitLog）：

1. 消息文件过期（默认72小时），且到达清理时点（默认是凌晨4点），删除过期文件。
2. 消息文件过期（默认72小时），且磁盘空间达到了水位线（默认75%），删除过期文件。
3. 磁盘已经达到必须释放的上限（85%水位线）的时候，则开始批量清理文件（无论是否过期），直到空间充足。

注：若磁盘空间达到危险水位线（默认90%），出于保护自身的目的，broker会拒绝写入服务。

这样设计带来的好处

消息的物理文件一直存在，消费逻辑只是听客户端的决定而搜索出对应消息进行，这样做，笔者认为，有以下几个好处：

1. 一个消息很可能需要被N个消费组（设计上很可能就是系统）消费，但消息只需要存储一份，消费进度单独记录即可。这给强大的消息堆积能力提供了很好的支持——一个消息无需复制N份，就可服务N个消费组。
2. 由于消费从哪里消费的决定权一直都是客户端决定，所以只要消息还在，就可以消费到，这使得RocketMQ可以支持其他传统消息中间件不支持的回溯消费。即我可以通过设置消费进度回溯，就可以让我的消费组重新像放快照一样消费历史消息；或者我需要另一个系统也复制历史的数据，只需要另起一个消费组从头消费即可（前提是消息文件还存在）。
3. 消息索引服务。只要消息还存在就能被搜索出来。所以可以依靠消息的索引搜索出消息的各种原信息，方便事后排查问题。

注：在消息清理的时候，由于消息文件默认是1GB，所以在清理的时候其实是在删除一个大文件操作，这对于IO的压力是非常大的，这时候如果有消息写入，写入的耗时会明显变高。这个现象可以在凌晨4点（默认删时间时点）后的附近观察得到。

RocketMQ官方建议Linux下文件系统改为Ext4，对于文件删除操作相比Ext3有非常明显的提升。

跳过历史消息的处理

由于消息本身是没有过期的概念，只有文件才有过期的概念。那么对于很多业务场景——一个消息如果太老，是无需要被消费的，是不合适的。

这种需要跳过历史消息的场景，在RocketMQ要怎么实现呢？

对于一个全新的消费组，PushConsumer默认就是跳过以前的消息而从最尾开始消费的，解析请参看RocketMQ——消息ACK机制及消费进度管理相关章节。

但对于已存在的消费组，RocketMQ没有内置的跳过历史消息的实现，但有以下手段可以解决：

1. 自身的消费代码按照日期过滤，太老的消息直接过滤。如：

   1 2 3 4 5 6 7 8 9 10 11 12

   @Override public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) { for(MessageExt msg: msgs){ if(System.currentTimeMillis()-msg.getBornTimestamp()>60*1000) {//一分钟之前的认为过期 continue;//过期消息跳过 } //do consume here } return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; }

2. 自身的消费代码代码判断消息的offset和MAX_OFFSET相差很远，认为是积压了很多，直接return CONSUME_SUCCESS过滤。

   1 2 3 4 5 6 7 8 9 10 11 12 13

   @Override public ConsumeConcurrentlyStatus consumeMessage(// List<MessageExt> msgs, // ConsumeConcurrentlyContext context) { long offset = msgs.get(0).getQueueOffset(); String maxOffset = msgs.get(0).getProperty(MessageConst.PROPERTY_MAX_OFFSET); long diff = Long. parseLong(maxOffset) - offset; if (diff > 100000) { //消息堆积了10W情况的特殊处理 return ConsumeConcurrentlyStatus. CONSUME_SUCCESS; } //do consume here return ConsumeConcurrentlyStatus. CONSUME_SUCCESS; }

3. 消费者启动前，先调整该消费组的消费进度，再开始消费。可以人工使用控制台命令resetOffsetByTime把消费进度调整到后面，再启动消费。

4. 原理同3，但使用代码来控制。代码中调用内部的运维接口，具体代码实例祥见ResetOffsetByTimeCommand.java

概览

欢迎来到 Nacos 的世界！

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

什么是 Nacos？

服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理：

Kubernetes Service

gRPC & Dubbo RPC Service

Spring Cloud RESTful Service

Nacos 的关键特性包括:

• 服务发现和服务健康监测
• 动态配置服务
• 动态 DNS 服务
• 服务及其元数据管理

Nacos 快速开始

这个快速开始手册是帮忙您快速在您的电脑上，下载、安装并使用 Nacos。

0.版本选择

您可以在Nacos的release notes及博客中找到每个版本支持的功能的介绍，当前推荐的稳定版本为1.4.2或2.0.1。

1.预备环境准备

Nacos 依赖 Java 环境来运行。如果您是从代码开始构建并运行Nacos，还需要为此配置 Maven环境，请确保是在以下版本环境中安装使用:

1. 64 bit OS，支持 Linux/Unix/Mac/Windows，推荐选用 Linux/Unix/Mac。
2. 64 bit JDK 1.8+；下载 & 配置。
3. Maven 3.2.x+；下载 & 配置。

下载编译后压缩包方式

您可以从 最新稳定版本 下载 nacos-server-$version.zip 包。

解压nacos-server-1.4.2.zip

Windows

启动命令(standalone代表着单机模式运行，非集群模式):

1
2

$ cd bin/
$ startup.cmd -m standalone

单机模式支持mysql

在0.7版本之前，在单机模式时nacos使用嵌入式数据库实现数据的存储，不方便观察数据存储的基本情况。0.7版本增加了支持mysql数据源能力，具体的操作步骤：

• 1.安装数据库，版本要求：5.6.5+
• 2.初始化mysql数据库，数据库初始化文件：nacos-mysql.sql
• 3.修改conf/application.properties文件，增加支持mysql数据源配置（目前只支持mysql），添加mysql数据源的url、用户名和密码。

1
2
3
4
5
6
7
8
9
10
11
12
13

#*************** Config Module Related Configurations ***************#
### If use MySQL as datasource:
spring.datasource.platform=mysql

### Count of DB:
# 数据库实例数量
db.num=1

# 数据库连接信息，如果是 MySQL 8.0+ 版本需要添加 serverTimezone=Asia/Shanghai
### Connect URL of DB:
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true
db.user=root
db.password=root

配置好数据库然后重启nacos如下:

访问ip:8848/nacos

http://192.168.2.159:8848/nacos/index.html

输入用户名 nacos 密码 nacos

这样就启动配置成功!

1

mysql> show engines;

一、InnoDB存储引擎

InnoDB是MySQL的默认事务型引擎，也是最重要、使用最广泛的存储引擎。它被设计 用来处理大量的短期(short-lived)事务，短期事务大部分情况是正常提交的，很少会被回滚。InnoDB的性能和自动崩溃恢复特性，使得它在非事务型存储的需求中也很流 行。除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎。 □D＞如果要学习存储引擎，InnoDB也是一个非常好的值得花最多的时间去深入学习的对象， 收益肯定比将时间平均花在每个存储引擎的学习上要高得多。

InnoDB的历史

InnoDB有着复杂的发布历史，了解一下这段历史对于理解InnoDB很有帮助。2008年， 发布了所谓的InnoDB plugin,适用于MySQL 5.1版本，但这是Oracle创建的下一代 InnoDB引擎，其拥有者是InnoDB而不是MySQL。这基于很多原因，这些原因如果要一一道来，恐怕得喝掉好几桶啤酒。MySQL默认还是选择了集成旧的InnoDB引擎。当 然用户可以自行选择使用新的性能更好、扩展性更佳的InnoDB plugin来覆盖旧的版本。 直到最后，在Oracle收购了 Sun公司后发布的MySQL 5.5中才彻底使用InnoDB plugin 替代了旧版本的InnoDB (是的，这也意味着InnoDB plugin已经是原生编译了，而不是编译成一个插件，但名字已经约定俗成很难更改)。

这个现代的InnoDB版本，也就是MySQL 5.1中所谓的InnoDB plugin,支持一些新特性， 诸如利用排序创建索引(building index by sorting)、删除或者增加索引时不需要复制全表数据、新的支持压缩的存储格式、新的大型列值如BLOB的存储方式，以及文件格式管 理等。很多用户在MySQL 5.1中没有使用InnoDB plugin,或许是因为他们没有注意到有这个区别。所以如果你使用的是MySQL 5.1, 一定要使用InnoDB plugin,真的比旧版本的InnoDB要好很多。

InnoDB是一个很重要的存储引擎，很多个人和公司都对其贡献代码，而不仅仅是 Oracle公司的开发团队。一些重要的贡献者包括Google、Yasufumi Kinoshita、Percona,、Facebook等，他们的一些改进被直接移植到官方版本，也有一些由InnoDB团队重新实现。 在过去的几年间，InnoDB的改进速度大大加快，主要的改进集中在可测量性、可扩展性、 可配置化、性能、各种新特性和对Windows的支持等方面。MySQL 5.6实验室预览版 和里程碑版也包含了一系列重要的InnoDB新特性。

为改善InnoDB的性能，Oracle投入了大量的资源，并做了很多卓有成效的工作(外部贡献者对此也提供了很大的帮助)。在本书的第二版中，我们注意到在超过四核CPU的系统中InnoDB表现不佳，而现在已经可以很好地扩展至24核的系统，甚至在某些场景， 32核或者更多核的系统中也表现良好。很多改进将在即将发布的MySQL 5.6中引入， 当然也还有机会做更进一步的改善。

InnoDB概览

InnoDB的数据存储在表空间(tablespace)中，表空间是由InnoDB管理的一个黑盒子， 由一系列的数据文件组成。在MySQL 4.1以后的版本中，InnoDB可以将每个表的数据 和索引存放在单独的文件中。InnoDB也可以使用裸设备作为表空间的存储介质，但现代的文件系统使得裸设备不再是必要的选择。

InnoDB采用MVCC来支持高并发，并且实现了四个标准的隔离级别。其默认级别是 REPEATABLE READ (可重复读)，并且通过间隙锁(next-key locking)策略防止幻读的出现。 间隙锁使得InnoDB不仅仅锁定査询涉及的行，还会对索引中的间隙进行锁定，以防止幻影行的插入。 -

InnoDB表是基于聚簇索引建立的，我们会在后面的章节详细讨论聚簇索引。IimoDB的 索引结构和MySQL的其他存储引擎有很大的不同，聚簇索引对主键査询有很髙的性能。 不过它的二级索引(secondary index,非主键索引)中必须包含主键列，所以如果主键 列很大的话，其他的所有索引都会很大。因此，若表上的索引较多的话，主键应当尽可 能的小。InnoDB的存储格式是平台独立的，也就是说可以将数据和索引文件从Intel平 台复制到PowerPC或者Sun SPARC平台。

InnoDB内部做了很多优化，包括从磁盘读取数据时釆用的可预测性预读，能够自动在 内存中创建hash索引以加速读操作的自适应哈希索引(adaptive hash index),以及能够 加速插入操作的插入缓冲区(insert buffer)等。本书后面将更详细地讨论这些内容。

InnoDB的行为是非常复杂的，不容易理解。如果使用了 InnoDB引擎，笔者强烈建议阅 读官方手册中的”InnoDB事务模型和锁” 一节。如果应用程序基于InnoDB构建，则事 先了解一下InnoDB的MVCC架构带来的一些微妙和细节之处是非常有必要的。存储引 擎要为所有用户甚至包括修改数据的用户维持一致性的视图，是非常复杂的工作。

作为事务型的存储引擎，InnoDB通过一些机制和工具支持真正的热备份，Oracle提供 的MySQL Enterprise Backup. Percona提供的开源的XtraBackup都可以做到这一点。 MySQL的其他存储引擎不支持热备份，要获取一致性视图需要停止对所有表的写入， 而在读写混合场景中，停止写入可能也意味着停止读取。

MylSAM存储引擎

在MySQL 5.1及之前的版本，MylSAM是默认的存储引擎。MylSAM提供了大量的特 性，包括全文索引、压缩、空间函数(GIS)等，但MylSAM不支持事务和行级锁，而且有一个毫无疑问的缺陷就是崩溃后无法安全恢复。正是由于MylSAM引擎的缘故，即 使MySQL支持事务已经很长时间了，在很多人的概念中MySQL还是非事务型的数据 库。尽管MylSAM引擎不支持事务、不支持崩溃后的安全恢复，但它绝不是一无是处的。对于只读的数据，或者表比较小、可以忍受修复（repair）操作，则依然可以继续使 用MylSAM （但请不要默认使用MylSAM,而是应当默认使用InnoDB）。

存储

MylSAM会将表存储在两个文件中：数据文件和索引文件，分别以.MYD和.MYI为扩展名。MylSAM表可以包含动态或者静态（长度固定）行。MySQL会根据表的定义来 决定采用何种行格式。MylSAM表可以存储的行记录数，一般受限于可用的磁盘空间， 或者操作系统中单个文件的最大尺寸。

在MySQL 5.0中，MylSAM表如果是变长行，则默认配置只能处理256TB的数据，因 .为指向数据记录的指针长度是6个字节。而在更早的版本中，指针长度默认是4字节，所以只能处理4GB的数据。而所有的MySQL版本都支持8字节的指针。要改变 MylSAM表指针的长度（调高或者调低），可以通过修改表的MAX_R0WS和AVG_R0W_ LENGTH选项的值来实现，两者相乘就是表可能达到的最大大小。修改这两个参数会导致 重建整个表和表的所有索引，这可能需要很长的时间才能完成。

MylSAM特性

作为MySQL最早的存储引擎之一，MylSAM有一些已经开发出来很多年的特性，可以 满足用户的实际需求。

加锁与并发

MylSAM对整张表加锁，而不是针对行。读取时会对需要读到的所有表加共享锁， 写入时则对表加排他锁。但是在表有读取査询的同时，也可以往表中插入新的记录 （这被称为并发插入，CONCURRENT INSERT） o

修复

对于MylSAM表，MySQL可以手工或者自动执行检査和修复操作，但这里说的修 复和事务.恢复以及崩溃恢复是不同的概念。执行表的修复可能导致一些数据丢失， 而且修复操作是非常慢的。可以通过CHECK TABLE mytable检査表的错误，如果有 错误可以通过执行REPAIR TABLE mytable进行修复。另外，如果MySQL服务器已 经关闭，也可以通过myisamchk命令行工具进行检査和修复操作。

索引特性

对于MylSAM表，即使是BLOB和TEXT等长字段，也可以基于其前500个字符创建

索引。MylSAM也支持全文索引，这是一种基于分词创建的索引，可以支持复杂的 査询。

延迟更新索引键(Delayed Key Write)

创建MylSAM表的时候，如果指定了 DELAY_KEY_WRITE选项，在每次修改执行完成 时，不会立刻将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区(in.memory key buffer),只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入到磁 盘。这种方式可以极大地提升写入性能，但是在数据库或者主机崩溃时会造成索引 损坏，需要执行修复操作。延迟更新索引键的特性，可以在全局设置，也可以为单 个表设置。

MylSAM压缩表

如果表在创建并导入数据以后，不会再进行修改操作，那么这样的表或许适合釆用- MylSAM压缩表。

可以使用myisampack对MylSAM表进行压缩(也叫打包pack)o压缩表是不能进行修 改的(除非先将表解除压缩，修改数据，然后再次压缩)。压缩表可以极大地减少磁盘 空间占用，因此也可以减少磁盘I/O,从而提升査询性能。压缩表也支持索引，但索引 也是只读的。

以现在的硬件能力，对大多数应用场景，读取压缩表数据时的解压带来的开销影响并不 大，而减少I/O带来的好处则要大得多。压缩时表中的记录是独立压缩的，所以读取单 行的时候不需要去解压整个表(甚至也不解压行所在的整个页面)。

MylSAM性能

MylSAM引擎设计简单，数据以紧密格式存储，所以在某些场景下的性能很好。 MylSAM有一些服务器级别的性能扩展限制，比如对索引键缓冲区(key cache)的 Mutex锁，MariaDB基于段(segment)的索引键缓冲区机制来避免该问题。但MylSAM 最典型的性能问题还是表锁的问题，如果你发现所有的査询都长期处于“Locked”状态， 那么毫无疑问表锁就是罪魁祸首。

MySQL内建的其他存储引擎

MySQL还有一些有特殊用途的存储引擎。在新版本中，有些可能因为一些原因已经不 再支持;另外还有些会继续支持，但是需要明确地启用后才能使用。

Archive 引擎

Archive存储引擎只支持INSERT和SELECT操作，在MySQL 5.1之前也不支持索引。

Archive引擎会缓存所有的写并利用zlib对插入的行进行压缩，所以比MylSAM表的磁 盘I/O更少。但是每次SELECT査询都需要执行全表扫描。所以Archive表适合日志和 数据釆集类应用，这类应用做数据分析时往往需要全表扫描。或者在一些需要更快速的 INSERT操作的场合下也可以使用。

Archive引擎支持行级锁和专用的缓冲区，所以可以实现高并发的插入。在一个査询开 始直到返回表中存在的所有行数之前，Archive引擎会阻止其他的SELECT执行，以实现 一致性读。另外，也实现了批量插入在完成之前对读操作是不可见的。这种机制模仿了 事务和MVCC的一些特性，但Archive引擎不是一个事务型的引擎，而是一个针对高速 插入和压缩做了优化的简单引擎。

Blackhole 引擎

Blackhole引擎没有实现任何的存储机制，它会丢弃所有插入的数据，不做任何保存。但 是服务器会记录Blackhole表的日志，所以可以用于复制数据到备库，或者只是简单地 记录到日志。这种特殊的存储引擎可以在一些特殊的复制架构和日志审核时发挥作用。 但这种应用方式我们碰到过很多问题，因此并不推荐。

CSV引擎

CSV引擎可以将普通的CSV文件（逗号分割值的文件）作为MySQL的表来处理，但 这种表不支持索引。CSV引擎可以在数据库运行时拷入或者拷出文件。可以将Excel 等电子表格软件中的数据存储为CSV文件，然后复制到MySQL数据目录下，就能在 MySQL中打开使用。同样，如果将数据写入到一个CSV引擎表，其他的外部程序也能 立即从表的数据文件中读取csv格式的数据。因此CSV引擎可以作为一种数据交换的 机制，非常有用。

Federated 引擎

Federated引擎是访问其他MySQL服务器的一个代理，它会创建一个到远程MySQL服 务器的客户端连接，并将査询传输到远程服务器执行，然后提取或者发送需要的数据。 最初设计该存储引擎是为了和企业级数据库如Microsoft SQL Server和Oracle的类似特 性竞争的，可以说更多的是一种市场行为。尽管该引擎看起来提供了一种很好的跨服务 器的灵活性，但也经常带来问题，因此默认是禁用的。MariaDB使用了它的一个后续改 进版本，叫做FederatedXo

Memory引擎

如果需要快速地访问数据，并且这些数据不会被修改，重启以后丢失也没有关系，那么 使用Memory表(以前也叫做HEAP表)是非常有用的。Memory表至少比MylSAM表 要快一个数量级，因为所有的数据都保存在内存中，不需要进行磁盘I/O。Memory表的 结构在重启以后还会保留，但数据会丢失。

Memroy表在很多场景可以发挥好的作用：

• 用于査找(lookup)或者映射(mapping)表，例如将邮编和州名映射的表。

• 用于缓存周期性聚合数据(periodically aggregated data)的结果。

• 用于保存数据分析中产生的中间数据。

Memory表支持Hash索引，因此査找操作非常快。虽然Memory表的速度非常快，但还 是无法取代传统的基于磁盘的表。Memroy表是表级锁，因此并发写入的性能较低。它 不支持BLOB或TEXT类型的列，并且每行的长度是固定的，所以即使指定了 VARCHAR列， 实际存储时也会转换成CHAR,这可能导致部分内存的浪费(其中一些限制在Percona版 本已经解决)。

如果MySQL在执行査询的过程中需要使用临时表来保存中间结果，内部使用的临时表 就是Memory表。如果中间结果太大超出了 Memory表的限制，或者含有BLOB或TEXT 字段，则临时表会转换成MylSAM表。在后续的章节还会继续讨论该问题。

人们经常混淆Memory表和临时表。临时表是指使用CREATE TEMPORARY TABLE语句 创建的表，它可以使用任何存储引擎，因此和Memory表不是一回事。临时表只在 单个连接中可见，当连接断开时，临时表也将不复存在。

Merge引擎

Merge引擎是MylSAM引擎的一个变种。Merge表是由多个MylSAM表合并而来的虚 拟表。如果将MySQL用于日志或者数据仓库类应用，该引擎可以发挥作用。但是引入 分区功能后，该引擎已经被放弃(参考第7章)。

NDB集群引擎

2003年，当时的MySQL AB公司从索尼爱立信公司收购了 NDB数据库，然后开发了 NDB集群存储引擎，作为SQL和NDB原生协议之间的接口。MySQL服务器、NDB集 群存储引擎，以及分布式的、share.nothing的、容灾的、高可用的NDB数据库的组合， 被称为MySQL集群(MySQL Cluster)

第三方存储引擎

OLTP类引擎等不多介绍了。

一步一步推导出 Mysql 索引的底层数据结构。

Mysql 作为互联网中非常热门的数据库，其底层的存储引擎和数据检索引擎的设计非常重要，尤其是 Mysql 数据的存储形式以及索引的设计，决定了 Mysql 整体的数据检索性能。

我们知道，索引的作用是做数据的快速检索，而快速检索的实现的本质是数据结构。通过不同数据结构的选择，实现各种数据快速检索。在数据库中，高效的查找算法是非常重要的，因为数据库中存储了大量数据，一个高效的索引能节省巨大的时间。比如下面这个数据表，如果 Mysql 没有实现索引算法，那么查找 id=7 这个数据，那么只能采取暴力顺序遍历查找，找到 id=7 这个数据需要比较 7 次，如果这个表存储的是 1000W 个数据，查找 id=1000W 这个数据那就要比较 1000W 次，这种速度是不能接受的。

一、Mysql 索引底层数据结构选型

1. 哈希表（Hash）

哈希表是做数据快速检索的有效利器。

哈希算法：也叫散列算法，就是把任意值(key)通过哈希函数变换为固定长度的 key 地址，通过这个地址进行具体数据的数据结构。

考虑这个数据库表 user，表中一共有 7 个数据，我们需要检索 id=7 的数据，SQL 语法是：

1

select \* from user where id=7;

哈希算法首先计算存储 id=7 的数据的物理地址 addr=hash(7)=4231，而 4231 映射的物理地址是 0x77，0x77 就是 id=7 存储的额数据的物理地址，通过该独立地址可以找到对应 user_name=’g’这个数据。这就是哈希算法快速检索数据的计算过程。

但是哈希算法有个数据碰撞的问题，也就是哈希函数可能对不同的 key 会计算出同一个结果，比如 hash(7)可能跟 hash(199)计算出来的结果一样，也就是不同的 key 映射到同一个结果了，这就是碰撞问题。解决碰撞问题的一个常见处理方式就是链地址法，即用链表把碰撞的数据接连起来。计算哈希值之后，还需要检查该哈希值是否存在碰撞数据链表，有则一直遍历到链表尾，直达找到真正的 key 对应的数据为止。

从算法时间复杂度分析来看，哈希算法时间复杂度为 O（1），检索速度非常快。比如查找 id=7 的数据，哈希索引只需要计算一次就可以获取到对应的数据，检索速度非常快。但是 Mysql 并没有采取哈希作为其底层算法，这是为什么呢？

因为考虑到数据检索有一个常用手段就是范围查找，比如以下这个 SQL 语句：

1

select \* from user where id \>3;

针对以上这个语句，我们希望做的是找出 id>3 的数据，这是很典型的范围查找。如果使用哈希算法实现的索引，范围查找怎么做呢？一个简单的思路就是一次把所有数据找出来加载到内存，然后再在内存里筛选筛选目标范围内的数据。但是这个范围查找的方法也太笨重了，没有一点效率而言。

所以，使用哈希算法实现的索引虽然可以做到快速检索数据，但是没办法做数据高效范围查找，因此哈希索引是不适合作为 Mysql 的底层索引的数据结构。

1. 二叉查找树(BST)

二叉查找树是一种支持数据快速查找的数据结构，如图下所示:

二叉查找树的时间复杂度是 O(lgn)，比如针对上面这个二叉树结构，我们需要计算比较 3 次就可以检索到 id=7 的数据，相对于直接遍历查询省了一半的时间，从检索效率上看来是能做到高速检索的。此外二叉树的结构能不能解决哈希索引不能提供的范围查找功能呢？

答案是可以的。观察上面的图，二叉树的叶子节点都是按序排列的，从左到右依次升序排列，如果我们需要找 id>5 的数据，那我们取出节点为 6 的节点以及其右子树就可以了，范围查找也算是比较容易实现。

但是普通的二叉查找树有个致命缺点：极端情况下会退化为线性链表，二分查找也会退化为遍历查找，时间复杂退化为 O（N），检索性能急剧下降。比如以下这个情况，二叉树已经极度不平衡了，已经退化为链表了，检索速度大大降低。此时检索 id=7 的数据的所需要计算的次数已经变为 7 了。

在数据库中，数据的自增是一个很常见的形式，比如一个表的主键是 id，而主键一般默认都是自增的，如果采取二叉树这种数据结构作为索引，那上面介绍到的不平衡状态导致的线性查找的问题必然出现。因此，简单的二叉查找树存在不平衡导致的检索性能降低的问题，是不能直接用于实现 Mysql 底层索引的。

1. AVL 树和红黑树

二叉查找树存在不平衡问题，因此学者提出通过树节点的自动旋转和调整，让二叉树始终保持基本平衡的状态，就能保持二叉查找树的最佳查找性能了。基于这种思路的自调整平衡状态的二叉树有 AVL 树和红黑树。

首先简单介绍红黑树，这是一颗会自动调整树形态的树结构，比如当二叉树处于一个不平衡状态时，红黑树就会自动左旋右旋节点以及节点变色，调整树的形态，使其保持基本的平衡状态（时间复杂度为 O（logn）），也就保证了查找效率不会明显减低。比如从 1 到 7 升序插入数据节点，如果是普通的二叉查找树则会退化成链表，但是红黑树则会不断调整树的形态，使其保持基本平衡状态，如下图所示。下面这个红黑树下查找 id=7 的所要比较的节点数为 4，依然保持二叉树不错的查找效率。

红黑树拥有不错的平均查找效率，也不存在极端的 O(n)情况，那红黑树作为 Mysql 底层索引实现是否可以呢？其实红黑树也存在一些问题，观察下面这个例子。

红黑树顺序插入 1~7 个节点，查找 id=7 时需要计算的节点数为 4。

红黑树顺序插入 1~16 个节点，查找 id=16 需要比较的节点数为 6 次。观察一下这个树的形态，是不是当数据是顺序插入时，树的形态一直处于“右倾”的趋势呢？从根本上上看，红黑树并没有完全解决二叉查找树虽然这个“右倾”趋势远没有二叉查找树退化为线性链表那么夸张，但是数据库中的基本主键自增操作，主键一般都是数百万数千万的，如果红黑树存在这种问题，对于查找性能而言也是巨大的消耗，我们数据库不可能忍受这种无意义的等待的。

现在考虑另一种更为严格的自平衡二叉树 AVL 树。因为 AVL 树是个绝对平衡的二叉树，因此他在调整二叉树的形态上消耗的性能会更多。

AVL 树顺序插入 1~7 个节点，查找 id=7 所要比较节点的次数为 3。

AVL 树顺序插入 1~16 个节点，查找 id=16 需要比较的节点数为 4。从查找效率而言，AVL 树查找的速度要高于红黑树的查找效率（AVL 树是 4 次比较，红黑树是 6 次比较）。从树的形态看来，AVL 树不存在红黑树的“右倾”问题。也就是说，大量的顺序插入不会导致查询性能的降低，这从根本上解决了红黑树的问题。

总结一下 AVL 树的优点：

1. 不错的查找性能（O（logn）），不存在极端的低效查找的情况。
2. 可以实现范围查找、数据排序。

看起来 AVL 树作为数据查找的数据结构确实很不错，但是 AVL 树并不适合做 Mysql 数据库的索引数据结构，因为考虑一下这个问题：

数据库查询数据的瓶颈在于磁盘 IO，如果使用的是 AVL 树，我们每一个树节点只存储了一个数据，我们一次磁盘 IO 只能取出来一个节点上的数据加载到内存里，那比如查询 id=7 这个数据我们就要进行磁盘 IO 三次，这是多么消耗时间的。所以我们设计数据库索引时需要首先考虑怎么尽可能减少磁盘 IO 的次数。

磁盘 IO 有个有个特点，就是从磁盘读取 1B 数据和 1KB 数据所消耗的时间是基本一样的，我们就可以根据这个思路，我们可以在一个树节点上尽可能多地存储数据，一次磁盘 IO 就多加载点数据到内存，这就是 B 树，B+树的的设计原理了。

1. B 树

下面这个 B 树，每个节点限制最多存储两个 key，一个节点如果超过两个 key 就会自动分裂。比如下面这个存储了 7 个数据 B 树，只需要查询两个节点就可以知道 id=7 这数据的具体位置，也就是两次磁盘 IO 就可以查询到指定数据，优于 AVL 树。

下面是一个存储了 16 个数据的 B 树，同样每个节点最多存储 2 个 key，查询 id=16 这个数据需要查询比较 4 个节点，也就是经过 4 次磁盘 IO。看起来查询性能与 AVL 树一样。

但是考虑到磁盘 IO 读一个数据和读 100 个数据消耗的时间基本一致，那我们的优化思路就可以改为：尽可能在一次磁盘 IO 中多读一点数据到内存。这个直接反映到树的结构就是，每个节点能存储的 key 可以适当增加。

当我们把单个节点限制的 key 个数设置为 6 之后，一个存储了 7 个数据的 B 树，查询 id=7 这个数据所要进行的磁盘 IO 为 2 次。

一个存储了 16 个数据的 B 树，查询 id=7 这个数据所要进行的磁盘 IO 为 2 次。相对于 AVL 树而言磁盘 IO 次数降低为一半。

所以数据库索引数据结构的选型而言，B 树是一个很不错的选择。总结来说，B 树用作数据库索引有以下优点：

1. 优秀检索速度，时间复杂度：B 树的查找性能等于 O（h*logn），其中 h 为树高，n 为每个节点关键词的个数；
2. 尽可能少的磁盘 IO，加快了检索速度；
3. 可以支持范围查找。
4. B+树

B 树和 B+树有什么不同呢？

第一，B 树一个节点里存的是数据，而 B+树存储的是索引（地址），所以 B 树里一个节点存不了很多个数据，但是 B+树一个节点能存很多索引，B+树叶子节点存所有的数据。

第二，B+树的叶子节点是数据阶段用了一个链表串联起来，便于范围查找。

通过 B 树和 B+树的对比我们看出，B+树节点存储的是索引，在单个节点存储容量有限的情况下，单节点也能存储大量索引，使得整个 B+树高度降低，减少了磁盘 IO。其次，B+树的叶子节点是真正数据存储的地方，叶子节点用了链表连接起来，这个链表本身就是有序的，在数据范围查找时，更具备效率。因此 Mysql 的索引用的就是 B+树，B+树在查找效率、范围查找中都有着非常不错的性能。

二、Innodb 引擎和 Myisam 引擎的实现

Mysql 底层数据引擎以插件形式设计，最常见的是 Innodb 引擎和 Myisam 引擎，用户可以根据个人需求选择不同的引擎作为 Mysql 数据表的底层引擎。我们刚分析了，B+树作为 Mysql 的索引的数据结构非常合适，但是数据和索引到底怎么组织起来也是需要一番设计，设计理念的不同也导致了 Innodb 和 Myisam 的出现，各自呈现独特的性能。

MyISAM 虽然数据查找性能极佳，但是不支持事务处理。Innodb 最大的特色就是支持了 ACID 兼容的事务功能，而且他支持行级锁。Mysql 建立表的时候就可以指定引擎，比如下面的例子，就是分别指定了 Myisam 和 Innodb 作为 user 表和 user2 表的数据引擎。

执行这两个指令后，系统出现了以下的文件，说明这两个引擎数据和索引的组织方式是不一样的。

Innodb 创建表后生成的文件有：

• frm:创建表的语句
• idb:表里面的数据+索引文件

Myisam 创建表后生成的文件有

• frm:创建表的语句
• MYD:表里面的数据文件（myisam data）
• MYI:表里面的索引文件（myisam index）

从生成的文件看来，这两个引擎底层数据和索引的组织方式并不一样，MyISAM 引擎把数据和索引分开了，一人一个文件，这叫做非聚集索引方式；Innodb 引擎把数据和索引放在同一个文件里了，这叫做聚集索引方式。下面将从底层实现角度分析这两个引擎是怎么依靠 B+树这个数据结构来组织引擎实现的。

1. MyISAM 引擎的底层实现（非聚集索引方式）

MyISAM 用的是非聚集索引方式，即数据和索引落在不同的两个文件上。MyISAM 在建表时以主键作为 KEY 来建立主索引 B+树，树的叶子节点存的是对应数据的物理地址。我们拿到这个物理地址后，就可以到 MyISAM 数据文件中直接定位到具体的数据记录了。

当我们为某个字段添加索引时，我们同样会生成对应字段的索引树，该字段的索引树的叶子节点同样是记录了对应数据的物理地址，然后也是拿着这个物理地址去数据文件里定位到具体的数据记录。

1. Innodb 引擎的底层实现（聚集索引方式）

InnoDB 是聚集索引方式，因此数据和索引都存储在同一个文件里。首先 InnoDB 会根据主键 ID 作为 KEY 建立索引 B+树，如左下图所示，而 B+树的叶子节点存储的是主键 ID 对应的数据，比如在执行 select * from user_info where id=15 这个语句时，InnoDB 就会查询这颗主键 ID 索引 B+树，找到对应的 user_name=’Bob’。

这是建表的时候 InnoDB 就会自动建立好主键 ID 索引树，这也是为什么 Mysql 在建表时要求必须指定主键的原因。当我们为表里某个字段加索引时 InnoDB 会怎么建立索引树呢？比如我们要给 user_name 这个字段加索引，那么 InnoDB 就会建立 user_name 索引 B+树，节点里存的是 user_name 这个 KEY，叶子节点存储的数据的是主键 KEY。注意，叶子存储的是主键 KEY！拿到主键 KEY 后，InnoDB 才会去主键索引树里根据刚在 user_name 索引树找到的主键 KEY 查找到对应的数据。

问题来了，为什么 InnoDB 只在主键索引树的叶子节点存储了具体数据，但是其他索引树却不存具体数据呢，而要多此一举先找到主键，再在主键索引树找到对应的数据呢?

其实很简单，因为 InnoDB 需要节省存储空间。一个表里可能有很多个索引，InnoDB 都会给每个加了索引的字段生成索引树，如果每个字段的索引树都存储了具体数据，那么这个表的索引数据文件就变得非常巨大（数据极度冗余了）。从节约磁盘空间的角度来说，真的没有必要每个字段索引树都存具体数据，通过这种看似“多此一举”的步骤，在牺牲较少查询的性能下节省了巨大的磁盘空间，这是非常有值得的。

在进行 InnoDB 和 MyISAM 特点对比时谈到，MyISAM 查询性能更好，从上面索引文件数据文件的设计来看也可以看出原因：MyISAM 直接找到物理地址后就可以直接定位到数据记录，但是 InnoDB 查询到叶子节点后，还需要再查询一次主键索引树，才可以定位到具体数据。等于 MyISAM 一步就查到了数据，但是 InnoDB 要两步，那当然 MyISAM 查询性能更高。

本文首先探讨了哪种数据结构更适合作为 Mysql 底层索引的实现，然后再介绍了 Mysql 两种经典数据引擎 MyISAM 和 InnoDB 的底层实现。最后再总结一下什么时候需要给你的表里的字段加索引吧：

1. 较频繁的作为查询条件的字段应该创建索引；
2. 唯一性太差的字段不适合单独创建索引，即使该字段频繁作为查询条件；
3. 更新非常频繁的字段不适合创建索引。

原文链接：
https://zhuanlan.zhihu.com/p/113917726

1. 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2. 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

3. 应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4. 应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如果or的所有字段都有索引还是会走索迎查询，如：

select id from t where num=10 or num=20

可以这样查询：

select id from t where num=10
union all
select id from t where num=20

5. in 和 not in 也要慎用，否则会导致全表扫描，如：

select id from t where num in(1,2,3)

对于连续的数值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

6. 下面的查询也将导致全表扫描：

select id from t where name like ‘%abc%’ 和 select id from t where name like ‘%abc’

只有like abc% 索引才有效，若要提高效率，可以考虑全文检索

7. 如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

select id from t where num=@num

可以改为强制查询使用索引：

select id from t with(index(索引名)) where num=@num

8. 应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where num/2=100

应改为:

select id from t where num=100*2

9. 应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where substring(name,1,3)=’abc’–name以abc开头的id
select id from t where datediff(day,createdate,’2005-11-30’)=0–‘2005-11-30’生成的id

应改为:

select id from t where name like ‘abc%’

select id from t where createdate>=’2005-11-30’ and createdate<’2005-12-1’

10. 不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

11. 在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
    对于复合索引：Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。

例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3种组合进行查找，但不支持 b,c进行查找 .当最左侧字段是常量引用时，索引就十分有效

12. 不要写一些没有意义的查询，如需要生成一个空表结构：

select col1,col2 into #t from t where 1=0

这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：

create table #t(…)

13. 很多时候用 exists 代替 in 是一个好的选择：

select num from a where num in(select num from b)

用下面的语句替换：

select num from a where exists(select 1 from b where num=a.num)

14. 并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。

原文链接：https://blog.csdn.net/BestDD/article/details/113359124

1. 条件中有or，即使其中有条件带索引也不会使用；
2. 对于多列索引，不使用的第一部分，则不会使用索引；
3. like查询以%开头，索引无效；
4. 当字段类型为字符串时，条件中数据没有使用引号引用。

索引并不是时时都会生效的，比如以下几种情况，将导致索引失效：

1. 如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)

注意：要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引

2. 对于多列索引，不是使用的第一部分，则不会使用索引

3. like查询是以%开头，索引无效；当like前缀没有%，后缀有%时，索引有效。

4. 如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引

5. 如果mysql估计使用全表扫描要比使用索引快,则不使用索引

此外，查看索引的使用情况

show status like ‘Handler_read%’;

大家可以注意：

handler_read_key:这个值越高越好，越高表示使用索引查询到的次数

handler_read_rnd_next:这个值越高，说明查询低效

1) 没有查询条件，或者查询条件没有建立索引

2) 在查询条件上没有使用引导列

3) 查询的数量是大表的大部分，应该是30％以上。

4) 索引本身失效

5) 查询条件使用函数在索引列上，或者对索引列进行运算，运算包括(+，-，*，/，! 等)

错误的例子：

select * from test where id-1=9;

正确的例子：

select * from test where id=10;

6) 对小表查询

7) 提示不使用索引

8) 统计数据不真实

9) CBO计算走索引花费过大的情况。其实也包含了上面的情况，这里指的是表占有的block要比索引小。

10) 隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误. 由于表的字段tu_mdn定义为varchar2(20),但在查询时把该字段作为number类型以where条件传给Oracle,这样会导致索引失效. .

错误的例子：

select * from test where tu_mdn=13333333333;

正确的例子：

select * from test where tu_mdn=’13333333333’;

12) 1,<> 2,单独的>,

13) like “%_” 百分号在前.

14) 表没分析.

15) 单独引用复合索引里非第一位置的索引列.

16) 字符型字段为数字时在where条件里不添加引号.

17) 对索引列进行运算.需要建立函数索引.

18) not in ,not exist.

19) 当变量采用的是times变量，而表的字段采用的是date变量时.或相反情况。

20) B-tree索引 is null不会走,is not null会走,位图索引 is null,is not null 都会走

21) 联合索引 is not null 只要在建立的索引列(不分先后)都会走, in null时 必须要和建立索引第一列一起使用,当建立索引第一位置条件是is null 时,其他建立索引的列可以是is null(但必须在所有列 都满足is null的时候),或者=一个值； 当建立索引的第一位置是=一个值时,其他索引列可以是任何情况(包括is null =一个值),以上两种情况索引都会走。其他情况不会走。

1. B-树索引

目前大多数索引都是采用B-树来存储，其包含组件有：

• 叶子节点：包含的条目直接指向表里的数据行。叶子节点之间彼此相连，一个叶子节点有一个指向下一个叶子节点的指针。
• 分支节点：包含的条目指向索引里其他的分支节点或者叶子节点。
• 根节点：一个 B-树索引只有一个根节点，实际上就是位于树的最顶端的分支节点。

2. 哈希索引

哈希索引也称为散列索引或 HASH 索引。MySQL 目前仅有 MEMORY 存储引擎和 HEAP 存储引擎支持这类索引。其中，MEMORY 存储引擎可以支持 B-树索引和 HASH 索引，且将 HASH 当成默认索引。

哈希索引的最大特点是访问速度快，但也存在下面的一些缺点：

• MySQL 需要读取表中索引列的值来参与散列计算，散列计算是一个比较耗时的操作。也就是说，相对于 B-树索引来说，建立哈希索引会耗费更多的时间。
• 不能使用 HASH 索引排序。
• HASH 索引只支持等值比较，如”=” “IN()”或”<=>”。
• HASH 索引不支持键的部分匹配，因为在计算 HASH 值的时候是通过整个索引值来计算的。

逻辑区分

1. 普通索引

普通索引是 MySQL 中最基本的索引类型，它没有任何限制，唯一任务就是加快系统对数据的访问速度。允许重复值和空值。

关键字是 INDEX 或 KEY。

2. 唯一索引

唯一索引列的值必须唯一，允许有空值。如果是组合索引，则列值的组合必须唯一。

关键字是 UNIQUE。

3. 主键索引

主键索引是一种特殊的唯一索引，不允许值重复或者值为空。

关键字是 PRIMARY KEY。

4. 空间索引

空间索引是对空间数据类型的字段建立的索引，不允许空值，只能在存储引擎为 MyISAM 的表中创建。

关键字是 SPATIAL。

5. 全文索引

全文索引主要用来查找文本中的关键字，只能在 CHAR、VARCHAR 或 TEXT 类型的列上创建。只有 MyISAM 存储引擎支持，允许重复值和空值。

关键字是 FULLTEXT。

实际使用区分

1. 单列索引

单列索引可以是普通索引，也可以是唯一性索引，还可以是全文索引。只要保证该索引只对应一个字段即可。

2. 组合索引

组合索引也称为复合索引或多列索引。相对于单列索引来说，组合索引是将原表的多个列共同组成一个索引。

查询时，字段顺序需与索引顺序一致；LIKE时，首字符不能是 ‘%’，否则会影响索引使用。

Normal 普通索引

表示普通索引，大多数情况下都可以使用

Unique 唯一索引

表示唯一的，不允许重复的索引，如果该字段信息保证不会重复例如身份证号用作索引时，可设置为unique

约束唯一标识数据库表中的每一条记录，即在单表中不能用每条记录是唯一的（例如身份证就是唯一的），Unique(要求列唯一)和Primary Key(primary key = unique + not null 列唯一)约束均为列或列集合中提供了唯一性的保证，Primary Key是拥有自动定义的Unique约束，但是每个表中可以有多个Unique约束，但是只能有一个Primary Key约束。
mysql中创建Unique约束

Full Text 全文索引

表示全文收索，在检索长文本的时候，效果最好，短文本建议使用Index,但是在检索的时候数据量比较大的时候，现将数据放入一个没有全局索引的表中，然后在用Create Index创建的Full Text索引，要比先为一张表建立Full Text然后在写入数据要快的很多

FULLTEXT 用于搜索很长一篇文章的时候，效果最好。用在比较短的文本，如果就一两行字的，普通的 INDEX 也可以。

SPATIAL 空间索引

空间索引是对空间数据类型的字段建立的索引，MYSQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING、POLYGON。MYSQL使用SPATIAL关键字进行扩展，使得能够用于创建正规索引类型的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL，空间索引只能在存储引擎为MYISAM的表中创建

btree索引和hash索引的区别

1、BTREE（B树（可以是多叉树）） {主流使用}
2、HASH（key,value） 这种方式对范围查询支持得不是很好

hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。
可 能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。

（1）Hash 索引仅仅能满足”=”,”IN”和”<=>”查询，不能使用范围查询。

由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。

（2）Hash 索引无法被用来避免数据的排序操作。

由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算；

（3）Hash 索引不能利用部分索引键查询。

对于组合索引，Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值，而不是单独计算 Hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。

（4）Hash 索引在任何时候都不能避免表扫描。

前面已经知道，Hash 索引是将索引键通过 Hash 运算之后，将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中，由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash 索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。

（5）Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。

对于选择性比较低的索引键，如果创建 Hash 索引，那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下。

在实际操作过程中，应该选取表中哪些字段作为索引？

为了使索引的使用效率更高，在创建索引时，必须考虑在哪些字段上创建索引和创建什么类型的索引,有7大原则：

1. 选择唯一性索引
2. 为经常需要排序、分组和联合操作的字段建立索引
3. 为常作为查询条件的字段建立索引
4. 限制索引的数目
5. 尽量使用数据量少的索引
6. 尽量使用前缀来索引
7. 删除不再使用或者很少使用的索引
8. 经常更新修改的字段不要建立索引（针对mysql说，因为字段更改同时索引就要重新建立，排序，而Orcale好像是有这样的机制字段值更改了，它不立刻建立索引，排序索引，而是根据更改个数，时间段去做平衡索引这件事的）
9. 不推荐在同一列建多个索引

MySQL目前主要有以下几种索引类型：
1.普通索引
2.唯一索引
3.主键索引
4.组合索引
5.全文索引

二、语句

1
2

CREATE TABLE table_name[col_name data type]
[unique|fulltext][index|key][index_name](col_name[length])[asc|desc]

1. unique|fulltext为可选参数，分别表示唯一索引、全文索引
2. index和key为同义词，两者作用相同，用来指定创建索引
3. col_name为需要创建索引的字段列，该列必须从数据表中该定义的多个列中选择
4. index_name指定索引的名称，为可选参数，如果不指定，默认col_name为索引值
5. length为可选参数，表示索引的长度，只有字符串类型的字段才能指定索引长度
6. asc或desc指定升序或降序的索引值存储

三、索引类型

1.普通索引
是最基本的索引，它没有任何限制。它有以下几种创建方式：
（1）直接创建索引

1

CREATE INDEX index_name ON table(column(length))

（2）修改表结构的方式添加索引

1

ALTER TABLE table_name ADD INDEX index_name ON (column(length))

（3）创建表的时候同时创建索引

1
2
3
4
5
6
7
8

CREATE TABLE `table` (
    `id` int(11) NOT NULL AUTO_INCREMENT ,
    `title` char(255) CHARACTER NOT NULL ,
    `content` text CHARACTER NULL ,
    `time` int(10) NULL DEFAULT NULL ,
    PRIMARY KEY (`id`),
    INDEX index_name (title(length))
)

（4）删除索引

1

DROP INDEX index_name ON table

2.唯一索引
与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：
（1）创建唯一索引

1

CREATE UNIQUE INDEX indexName ON table(column(length))

（2）修改表结构

1

ALTER TABLE table_name ADD UNIQUE indexName ON (column(length))

（3）创建表的时候直接指定

1
2
3
4
5
6
7

CREATE TABLE `table` (
    `id` int(11) NOT NULL AUTO_INCREMENT ,
    `title` char(255) CHARACTER NOT NULL ,
    `content` text CHARACTER NULL ,
    `time` int(10) NULL DEFAULT NULL ,
    UNIQUE indexName (title(length))
);

3.主键索引
是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。一般是在建表的时候同时创建主键索引：

1
2
3
4
5

CREATE TABLE `table` (
    `id` int(11) NOT NULL AUTO_INCREMENT ,
    `title` char(255) NOT NULL ,
    PRIMARY KEY (`id`)
);

4.组合索引
指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀集合

1

ALTER TABLE `table` ADD INDEX name_city_age (name,city,age);

5.全文索引
主要用来查找文本中的关键字，而不是直接与索引中的值相比较。fulltext索引跟其它索引大不相同，它更像是一个搜索引擎，而不是简单的where语句的参数匹配。fulltext索引配合match against操作使用，而不是一般的where语句加like。它可以在create table，alter table ，create index使用，不过目前只有char、varchar，text 列上可以创建全文索引。值得一提的是，在数据量较大时候，现将数据放入一个没有全局索引的表中，然后再用CREATE index创建fulltext索引，要比先为一张表建立fulltext然后再将数据写入的速度快很多。
（1）创建表的适合添加全文索引

1
2
3
4
5
6
7
8

CREATE TABLE `table` (
    `id` int(11) NOT NULL AUTO_INCREMENT ,
    `title` char(255) CHARACTER NOT NULL ,
    `content` text CHARACTER NULL ,
    `time` int(10) NULL DEFAULT NULL ,
    PRIMARY KEY (`id`),
    FULLTEXT (content)
);

（2）修改表结构添加全文索引

1

ALTER TABLE article ADD FULLTEXT index_content(content)

（3）直接创建索引

1

CREATE FULLTEXT INDEX index_content ON article(content)

四、缺点

1. 虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行insert、update和delete。因为更新表时，不仅要保存数据，还要保存一下索引文件。
2. 建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会增长很快。
   索引只是提高效率的一个因素，如果有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。

五、注意事项

使用索引时，有以下一些技巧和注意事项：

1. 索引不会包含有null值的列
   只要列中包含有null值都将不会被包含在索引中，复合索引中只要有一列含有null值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为null。
2. 使用短索引
   对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个char(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
3. 索引列排序
   查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。
4. like语句操作
   一般情况下不推荐使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
5. 不要在列上进行运算
   这将导致索引失效而进行全表扫描，例如

1

SELECT * FROM table_name WHERE YEAR(column_name)<2017;

6. 不使用not in和<>操作

索引基础

要理解MySQL中索引是如何工作的，最简单的方法就是去看看一本书的“索引”部分: 如果想在一本书中找到某个特定主题，一般会先看书的“索引”，找到对应的页码。

在MySQL中，存储引擎用类似的方法使用索引，其先在索引中找到对应值，然后根据 匹配的索引记录找到对应的数据行。假如要运行下面的査询：

mysql> SELECT first_ame FROM sakila.actor WHERE actor_id = 5;

如果在actor_id列上建有索引，则MySQL将使用该索引找到actor_id为5的行，也 就是说，MySQL先在索引上按值进行査找，然后返回所有包含该值的数据行。

索引可以包含一个或多个列的值。如果索引包含多个列，那么列的顺序也十分重要，因 为MySQL只能高效地使用索引的最左前缀列。创建一个包含两个列的索引，和创建两 个只包含一列的索引是大不相同的，下面将详细介绍。

如果使用的是ORM,是否还需要关心索引？

简而言之：是的，仍然需要理解索引，即使是使用对象关系映射(ORM)工具。

(ORM)工具能够生产符合逻辑的、合法的查询(多数时候)，除非只是生成非常基本 的查询(例如仅是根据主键查询)，否则它很难生成适合索引的查询。无论是多么 复杂的(ORM)工具，在精妙和复杂的索引面前都是“浮云”。读完本章后面的内容 以后，你就会同意这个观点的！很多时候，即使是查询优化技术专家也很难兼顾到 各种情况，更别说(ORM) 了。

准备

• SpringBoot 2.1.12
• Sharding-JDBC 4.0.0
• Mybatis 3.x
• Mysql 8.0
• lombok

本文场景介绍

user表分表分为2个表，2个库

POM文件

pom文件引入如下相关依赖：

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>cn.cicoding</groupId>
        <artifactId>shardingsphere-example</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <groupId>cn.cicoding</groupId>
    <artifactId>sharding-db-read-write</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>sharding-db-read-write</name>
    <description>Demo project for Spring Boot</description>

    <properties>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.mybatis.spring.boot</groupId>
            <artifactId>mybatis-spring-boot-starter</artifactId>
            <version>2.0.1</version>
        </dependency>

        <dependency>
            <groupId>org.apache.shardingsphere</groupId>
            <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
        </dependency>

        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

相关代码实现

Controller代码

CicodingController代码

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
31
32
33
34
35

package cn.cicoding.controller;

import cn.cicoding.model.LouDong;
import cn.cicoding.service.LouDongService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class LouDongController {

@Autowired
private LouDongService louDongService;

@GetMapping("/lds")
public Object list() {
return louDongService.list();
}

@GetMapping("/ld/add")
public Object add() {
for (long i = 0; i < 10; i++) {
LouDong louDong = new LouDong();
louDong.setId(i+"a");
louDong.setCity("深圳");
louDong.setRegion("宝安");
louDong.setName("李四");
louDong.setLdNum("A");
louDong.setUnitNum("2");
louDongService.addLouDong(louDong);
}
return "success";
}

}

UserController代码

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
31
32
33
34
35
36
37
38
39
40
41
42

package cn.cicoding.controller;

import cn.cicoding.model.User;
import cn.cicoding.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class UserController {

@Autowired
private UserService userService;

@GetMapping("/users")
public Object list() {
return userService.list();
}

@GetMapping("/add")
public Object add() {
for (long i = 0; i < 100; i++) {
User user = new User();
user.setCity("深圳");
user.setName("李四");
userService.add(user);
}
return "success";
}

@GetMapping("/users/{id}")
public Object get(@PathVariable Long id) {
return userService.findById(id);
}

@GetMapping("/users/query")
public Object get(String name) {
return userService.findByName(name);
}

}

Service代码

CicodingService代码

1
2
3
4
5
6
7
8
9
10
11
12
13

package cn.cicoding.service;

import cn.cicoding.model.LouDong;

import java.util.List;

public interface CicodingService {

List<LouDong> list();

Long addLouDong(LouDong louDong);

}

UserService代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package cn.cicoding.service;

import java.util.List;

import cn.cicoding.model.User;

public interface UserService {

List<User> list();

Long add(User user);

User findById(Long id);

User findByName(String name);

}

CicodingServiceImpl代码

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

package cn.cicoding.service;

import java.util.List;

import cn.cicoding.model.LouDong;
import cn.cicoding.repository.LouDongRepository;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class CicodingServiceImpl implements CicodingService {

@Autowired
private LouDongRepository louDongRepository;

@Override
public List<LouDong> list() {
return louDongRepository.list();
}

@Override
public Long addLouDong(LouDong louDong) {
return louDongRepository.addLouDong(louDong);
}

}

UserServiceImpl代码

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
31
32
33
34

package cn.cicoding.service;

import java.util.List;

import cn.cicoding.model.User;
import cn.cicoding.repository.UserRepository;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class UserServiceImpl implements UserService {

@Autowired
private UserRepository userRepository;

public List<User> list() {
return userRepository.list();
}

public Long add(User user) {
return userRepository.addUser(user);
}

@Override
public User findById(Long id) {
return userRepository.findById(id);
}

@Override
public User findByName(String name) {
return userRepository.findByName(name);
}

}

Repository代码

CicodingRepository代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package cn.cicoding.repository;

import java.util.List;

import cn.cicoding.model.LouDong;
import org.apache.ibatis.annotations.Mapper;

@Mapper
public interface CicodingRepository {

Long addLouDong(LouDong louDong);

List<LouDong> list();
}

UserRepository代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

package cn.cicoding.repository;

import java.util.List;

import cn.cicoding.model.User;
import org.apache.ibatis.annotations.Mapper;

@Mapper
public interface UserRepository {

Long addUser(User user);

List<User> list();

User findById(Long id);

User findByName(String name);
}

Mapper.xml代码实现

CicodingMapper.xml

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
31
32

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="cn.cicoding.repository.CicodingMapper">
    
    <resultMap id="baseResultMap" type="cn.cicoding.model.Cicoding">
        <result column="id" property="id" jdbcType="VARCHAR" />
        <result column="city" property="city" jdbcType="VARCHAR" />
        <result column="region" property="region" jdbcType="VARCHAR" />
        <result column="name" property="name" jdbcType="VARCHAR" />
        <result column="ld_num" property="ldNum" jdbcType="VARCHAR" />
        <result column="unit_num" property="unitNum" jdbcType="VARCHAR" />
    </resultMap>
    
    <insert id="addLouDong">
        INSERT INTO loudong (
        id, city, region, name, ld_num, unit_num
        )
        VALUES (
        #{id,jdbcType=VARCHAR},
        #{city,jdbcType=VARCHAR},
        #{region,jdbcType=VARCHAR},
        #{name,jdbcType=VARCHAR},
        #{ldNum,jdbcType=VARCHAR},
        #{unitNum,jdbcType=VARCHAR}
        )
    </insert>
   
    <select id="list" resultMap="baseResultMap">
        SELECT ld.* FROM loudong ld
    </select>
    
</mapper>

UserMapper.xml

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
31
32
33

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="cn.cicoding.repository.UserRepository">
    
    <resultMap id="baseResultMap" type="cn.cicoding.model.User">
        <result column="id" property="id" jdbcType="INTEGER" />
        <result column="city" property="city" jdbcType="VARCHAR" />
        <result column="name" property="name" jdbcType="VARCHAR" />
    </resultMap>
    
    <insert id="addUser">
        INSERT INTO user (
           city, name
        )
        VALUES (
        #{city,jdbcType=VARCHAR},
        #{name,jdbcType=VARCHAR}
        )
    </insert>
   
    <select id="list" resultMap="baseResultMap">
        SELECT u.* FROM user u
    </select>

<select id="findById" resultMap="baseResultMap">
        SELECT u.* FROM user u WHERE u.id=#{id,jdbcType=INTEGER}
    </select>
    
    <select id="findByName" resultMap="baseResultMap">
        SELECT u.* FROM user u WHERE u.name=#{name,jdbcType=VARCHAR}
    </select>
    
</mapper>

实体类

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

package cn.cicoding.model;

import java.io.Serializable;

/**
 * 分表
 * @author cicoding
 *
 */
public class User implements Serializable {

private static final long serialVersionUID = -1205226416664488559L;

private Long id;

private String city = "";

private String name = "";

public Long getId() {
return id;
}

public void setId(Long id) {
this.id = id;
}

public String getCity() {
return city;
}

public void setCity(String city) {
this.city = city;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}


}

到这我们完成了基本的代码编写，由于sharding-jdbc是jar包，我们来看主要的配置信息

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

# Spring Boot版 Sharding JDBC 垂直拆分（不同的表在不同的库中）+ 读写分离
server.port=8084

# mybatis对应的映射文件路径
mybatis.mapper-locations=classpath:mapper/*.xml
# mybatis对应的实体类
mybatis.type-aliases-package=cn.cicoding.model

spring.shardingsphere.datasource.names=ds0,ds0slave,ds1,ds1slave


# 数据源
spring.shardingsphere.datasource.ds0.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds0.jdbc-url=jdbc:mysql://localhost:3306/ds_0?useSSL=false&useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
spring.shardingsphere.datasource.ds0.username=root
spring.shardingsphere.datasource.ds0.password=root

spring.shardingsphere.datasource.ds0slave.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds0slave.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds0slave.jdbc-url=jdbc:mysql://localhost:3306/ds0slave?useSSL=false&useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
spring.shardingsphere.datasource.ds0slave.username=root
spring.shardingsphere.datasource.ds0slave.password=root

spring.shardingsphere.datasource.ds1.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.ds1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds1.jdbc-url=jdbc:mysql://localhost:3306/ds_1?useSSL=false&useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
spring.shardingsphere.datasource.ds1.username=root
spring.shardingsphere.datasource.ds1.password=root

spring.shardingsphere.datasource.ds1slave.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.ds1slave.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds1slave.jdbc-url=jdbc:mysql://localhost:3306/ds1slave?useSSL=false&useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
spring.shardingsphere.datasource.ds1slave.username=root
spring.shardingsphere.datasource.ds1slave.password=root

# 绑定loudong表所在节点
spring.shardingsphere.sharding.tables.loudong.actual-data-nodes=ds1.loudong

# 绑定user表所在节点
spring.shardingsphere.sharding.tables.user.actual-data-nodes=ds0.user
spring.shardingsphere.sharding.tables.user.key-generator.column=id
spring.shardingsphere.sharding.tables.user.key-generator.type=SNOWFLAKE

# 读写分离
spring.shardingsphere.sharding.master-slave-rules.ds0.master-data-source-name=ds0
spring.shardingsphere.sharding.master-slave-rules.ds0.slave-data-source-names=ds0slave

spring.shardingsphere.sharding.master-slave-rules.ds1.master-data-source-name=ds1
spring.shardingsphere.sharding.master-slave-rules.ds1.slave-data-source-names=ds1slave

启动类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

package cn.cicoding;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

/**
 * Spring Boot版 Sharding JDBC 垂直拆分（不同的表在不同的库中）+ 读写分离
 */
@SpringBootApplication
public class ShardingDbReadWriteApplication {

public static void main(String[] args) {
SpringApplication.run(ShardingDbReadWriteApplication.class, args);
}

}

测试演示

启动启动类，访问http://localhost:8084/add

http://localhost:8084/cis

分别进入不同的库！

到此我们就实现了sharding-jdbc主从读写分离实现，更多配置请参考此处！