MySQL 8 中大小写敏感与不敏感排序规则的选择

pe7er2026-03-17 10:07

在 MySQL 数据库设计中，字符集（charset）和排序规则（collation）通常是在创建数据库或表时确定的配置，但它们会直接影响字符串比较、排序以及查询行为。

在 MySQL 8 中，常见的排序规则包括：

  • utf8mb4_bin
  • utf8mb4_unicode_ci
  • utf8mb4_0900_ai_ci

不同排序规则会影响字符串是否区分大小写、排序方式以及模糊查询行为。很多项目在建表时没有认真考虑，后期才在搜索或索引使用时遇到问题。

本文总结在 MySQL 8 中如何根据字段语义选择大小写敏感或不敏感的排序规则。

排序规则与大小写敏感

MySQL 排序规则决定了字符串比较方式。

常见类型可以分为两类。

大小写敏感（Binary Collation）

bin代表二进制，大小写敏感。

例如：

复制代码 
utf8mb4_bin

utf8mb4_bin 使用二进制方式比较字符串，本质上按 UTF-8 字节值进行比较，因此字符 A 与 a 是不同的。

示例：

sql 复制代码 
SELECT 'abc' = 'ABC' COLLATE utf8mb4_bin;

结果：

复制代码 
0

大小写不敏感（Case Insensitive Collation）

ci代表case insensitive大小写不敏感。 例如：

复制代码 
utf8mb4_unicode_ci
utf8mb4_0900_ai_ci

示例：

ini 复制代码 
SELECT 'abc' = 'ABC' COLLATE utf8mb4_unicode_ci;

结果：

复制代码 
1

这种差异会影响所有字符串操作，包括：

  • =
  • LIKE
  • ORDER BY
  • 索引匹配

适合使用大小写敏感排序规则的场景

大小写敏感通常适用于技术型字段，这些字段本身具有严格的字符含义，不应该因为大小写变化而被认为是相同值。

常见场景包括：

  • 用户名或登录名（部分系统区分大小写）
  • 密码哈希值
  • API Key / Token
  • UUID 或 Hash 字符串
  • Base64 编码
  • 文件路径

推荐使用：

sql 复制代码 
COLLATE utf8mb4_bin

示例：

sql 复制代码 
CREATE TABLE api_keys (
    id BIGINT PRIMARY KEY,
    api_key VARCHAR(128) COLLATE utf8mb4_bin,
    user_id BIGINT
);

这样可以确保字符串完全精确匹配。

适合使用大小写不敏感排序规则的场景

另一类字段属于用户输入文本，例如自然语言内容。

常见字段包括：

  • 用户昵称
  • 文章标题
  • 商品名称
  • 标签
  • 城市或地址
  • 评论内容

例如用户搜索 iphone 时通常希望匹配：

复制代码 
iphone
iPhone
IPHONE

因此推荐使用大小写不敏感排序规则：

复制代码 
utf8mb4_unicode_ci

或在 MySQL 8 中更推荐：

复制代码 
utf8mb4_0900_ai_ci

示例：

sql 复制代码 
CREATE TABLE articles (
    id BIGINT PRIMARY KEY,
    title VARCHAR(255) COLLATE utf8mb4_0900_ai_ci,
    content TEXT COLLATE utf8mb4_0900_ai_ci
);

这样 LIKE 查询和搜索体验会更友好。

为什么不建议全库使用 utf8mb4_bin

有些团队为了避免排序规则混乱，会选择全库统一使用 utf8mb4_bin。

虽然简单，但会带来明显问题。

搜索体验差

例如：

sql 复制代码 
SELECT * FROM products WHERE name LIKE 'iphone%';

如果字段是 utf8mb4_bin，则不会匹配：

复制代码 
iPhone

排序不符合语言习惯

utf8mb4_bin 按字节排序，而不是按语言规则排序。

因此 ORDER BY 的结果可能不符合人类阅读习惯。

模糊查询命中率低

用户输入通常不会严格区分大小写。

推荐的数据库设计方式

比较合理的设计方式是：

数据库默认使用大小写不敏感排序规则，少数需要精确匹配的字段单独使用 _bin。

示例：

sql 复制代码 
CREATE TABLE users (
    id BIGINT PRIMARY KEY,

    username VARCHAR(64) COLLATE utf8mb4_bin,

    email VARCHAR(128) COLLATE utf8mb4_0900_ai_ci,

    nickname VARCHAR(64) COLLATE utf8mb4_0900_ai_ci,

    password_hash VARCHAR(255) COLLATE utf8mb4_bin,

    bio TEXT COLLATE utf8mb4_0900_ai_ci
);

这种设计可以兼顾：

  • 安全字段精确匹配
  • 用户文本友好搜索

MySQL 8 推荐默认排序规则

如果是新项目，MySQL 8 推荐使用：

复制代码 
utf8mb4_0900_ai_ci

特点包括：

  • 基于 Unicode 9.0
  • 支持更多语言字符
  • 支持 emoji
  • 排序更符合语言规则
  • 忽略大小写与重音符号

对于大多数 Web 应用，这是最合理的默认选择。

已有表如何修改大小写敏感规则

在实际项目中，排序规则往往不是一开始就设计好的。随着业务发展，可能会出现以下情况：

  • 原本不区分大小写的字段，需要改为区分大小写
  • 新增字段，需要指定为大小写敏感
  • 整个表需要统一调整排序规则
  • 数据库默认排序规则需要调整

因此了解如何在 已有表结构中调整排序规则非常重要。

修改字段的排序规则

如果只是某个字段需要调整大小写敏感规则，可以直接修改字段的 COLLATE。

例如原字段：

sql 复制代码 
username VARCHAR(64) COLLATE utf8mb4_unicode_ci

需要改为大小写敏感：

sql 复制代码 
ALTER TABLE users 
MODIFY username VARCHAR(64)
CHARACTER SET utf8mb4
COLLATE utf8mb4_bin;

需要注意：

  • MODIFY 时必须写完整字段定义
  • 字符集和排序规则通常需要一起声明
  • 该操作会重建字段索引

新增大小写敏感字段

如果是新增字段，可以在 ADD COLUMN 时直接指定排序规则。

例如新增 API Key：

sql 复制代码 
ALTER TABLE users
ADD COLUMN api_key VARCHAR(128)
CHARACTER SET utf8mb4
COLLATE utf8mb4_bin;

这样该字段在比较时会区分大小写。

修改整张表的排序规则

如果希望整张表默认使用新的排序规则，可以使用：

sql 复制代码 
ALTER TABLE users 
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;

该操作会：

  • 修改表默认字符集
  • 修改所有未显式指定排序规则的字段
  • 重建表数据

注意：如果字段已经显式指定 COLLATE，则不会被覆盖。

注意：如果从字符集A转换成字符集B，存在无法转换的生僻字，MYSQL转换会报错，比如GBK转UTF8/utf8mb4，MYSQL会报错，最佳实践是先导出文件，对文件字符集进行转换，再导入。

修改数据库默认排序规则

如果希望新建表默认使用新的排序规则，可以修改数据库默认设置。

sql 复制代码 
ALTER DATABASE mydb
CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;

该操作只影响：

  • 未来新建的表
  • 不影响已有表

修改排序规则时需要注意的问题

唯一索引冲突

当从 大小写敏感改为不敏感 时，可能出现唯一索引冲突。

例如原数据：

复制代码 
UserA
usera

在 utf8mb4_bin 下是合法的，但在 utf8mb4_unicode_ci 下会被认为是相同值。

执行修改时可能报错：

复制代码 
Duplicate entry

因此修改前需要检查数据。

索引可能会被重建

修改字段排序规则时：

  • 索引会重建
  • 大表可能产生锁表
  • 需要评估执行时间

对于生产环境大表，建议：

  • 在低峰期执行
  • 或使用在线 DDL

LIKE 查询行为会变化

例如：

sql 复制代码 
SELECT * FROM users WHERE username LIKE 'abc%';

在不同排序规则下：

排序规则 是否匹配 Abc
utf8mb4_bin 否
utf8mb4_unicode_ci 是

修改排序规则后，查询结果可能会发生变化。

实际项目中的推荐做法

在业务系统中，一般采用以下策略：

数据库默认排序规则：

复制代码 
utf8mb4_0900_ai_ci

用户文本字段：

复制代码 
utf8mb4_0900_ai_ci

技术标识符字段：

复制代码 
utf8mb4_bin

例如：

sql 复制代码 
CREATE TABLE users (
    id BIGINT PRIMARY KEY,

    username VARCHAR(64) COLLATE utf8mb4_bin,

    email VARCHAR(128) COLLATE utf8mb4_0900_ai_ci,

    nickname VARCHAR(64) COLLATE utf8mb4_0900_ai_ci,

    password_hash VARCHAR(255) COLLATE utf8mb4_bin,

    api_key VARCHAR(128) COLLATE utf8mb4_bin
);

这种设计既能保证安全字段的精确匹配，又能保持良好的搜索体验。

无法修改字符集合排序规则的处理方案

在一些系统中，由于历史原因或生产环境限制，可能无法直接修改字段或表的排序规则。例如：

  • 表数据量非常大，修改 COLLATE 会导致长时间锁表
  • 字段存在唯一索引，修改排序规则可能产生冲突
  • 线上系统不允许执行重建表结构的操作
  • 依赖系统较多，修改排序规则风险较高

在这种情况下，可以通过其他方式解决大小写敏感问题。

使用函数统一大小写进行比较

一种简单的做法是对字段值和查询值统一转换大小写，例如转换为小写：

sql 复制代码 
SELECT id
FROM user
WHERE LOWER(name) = 'peter';

或者：

sql 复制代码 
SELECT id
FROM user
WHERE LOWER(name) = LOWER('Peter');

这种方式可以在任何排序规则下实现大小写不敏感比较。

但需要注意，这种写法存在明显问题。

索引会失效

当字段使用函数处理时，例如 LOWER(name)，数据库无法使用原有索引。

例如：

sql 复制代码 
WHERE LOWER(name) = 'peter'

优化器无法利用 name 字段上的索引，因此会进行 全表扫描。

如果数据量较大（例如百万级以上），查询性能会明显下降，因此不建议在高并发或大数据量场景使用。

使用生成列维护查询字段

另一种方式是使用 生成列（Generated Column） 来维护统一格式的字段，例如统一转换为小写。

例如：

sql 复制代码 
ALTER TABLE user
ADD COLUMN name_search VARCHAR(64)
GENERATED ALWAYS AS (LOWER(name)) STORED;

然后为生成列创建索引：

scss 复制代码 
CREATE INDEX idx_user_name_search ON user(name_search);

查询时使用生成列：

sql 复制代码 
SELECT id
FROM user
WHERE name_search = 'peter';

这种方式的优点是：

  • 查询仍然可以使用索引
  • 不需要修改原字段排序规则
  • 对现有业务影响较小

但需要注意：

  • 需要额外存储空间
  • 写入或更新时需要维护生成列
  • 需要额外维护索引

在写入频繁的业务中，需要评估写入性能影响。

增加搜索中间层（Elasticsearch）

当系统对搜索能力要求较高，同时又无法修改数据库排序规则时，可以引入专门的搜索引擎作为中间层，例如

Elasticsearch。

基本思路是：

  • MySQL 负责事务型数据存储
  • Elasticsearch 负责搜索
  • 数据通过同步机制写入 ES

典型架构如下：

markdown 复制代码 
应用服务
    │
    ├── 写入 MySQL
    │
    └── 同步数据 → Elasticsearch
                     │
                 搜索查询

在 Elasticsearch 中可以通过 normalizer 或 analyzer 实现统一大小写，例如使用 lowercase filter。

例如字段 mapping：

json 复制代码 
{
  "mappings": {
    "properties": {
      "name": {
        "type": "keyword",
        "normalizer": "lowercase"
      }
    }
  }
}

这样在 ES 中：

复制代码 
Peter
PETER
peter

都会被统一为：

复制代码 
peter

查询时即可实现大小写不敏感搜索，同时保持高性能。

优点

  • 查询性能高，适合大数据量
  • 支持复杂搜索能力（模糊搜索、分词、全文检索）
  • 不影响原有数据库结构
  • 可以支持更多搜索需求

缺点

  • 架构复杂度增加
  • 需要维护数据同步
  • 引入新的基础设施

三种方案对比

方案 是否使用索引 改造成本 适用场景
LOWER() 函数查询 否 低 小数据量、临时查询
生成列 + 索引 是 中 查询频繁但无法修改排序规则
引入 Elasticsearch 是 高 大规模搜索、复杂查询

小结

当无法修改数据库排序规则时，可以考虑三种解决方案：

函数转换方案：

sql 复制代码 
LOWER(column) = 'value'

实现简单，但会导致索引失效。

生成列方案：

sql 复制代码 
GENERATED COLUMN + INDEX

可以保持数据库索引性能，但会增加存储和写入成本。

搜索中间层方案：

MySQL + Elasticsearch

适合数据规模较大、搜索需求复杂的系统，同时也能解决大小写敏感问题。

在实际系统设计中，任何影响性能、推翻架构的方法都应该谨慎对待，应根据数据规模、查询复杂度以及系统架构选择最合适的方案。

数据库规范与设计建议

字符集和排序规则的选择，本质上属于 数据库设计阶段的重要决策。在系统上线并产生大量数据之后，再去修改这些基础属性往往成本很高，因此在建库和建表时应尽量提前规划。

在数据库设计规范中，一般建议将以下内容作为设计阶段需要确认的事项：

  • 数据库默认字符集
  • 数据库默认排序规则
  • 特殊字段是否需要大小写敏感
  • 唯一索引字段是否受排序规则影响
  • 是否存在跨系统共享数据库的情况

这些规则一旦确定，上线后不应轻易修改。

为什么不建议轻易修改排序规则或字符集

在生产环境中修改字符集或排序规则，通常会带来以下影响。

可能导致锁表

很多修改字符集或排序规则的操作，本质上会触发表结构重建，例如：

sql 复制代码 
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

对于大表来说，该操作可能需要较长时间，在某些情况下还会导致表级锁或元数据锁（MDL），影响线上业务读写。

如果表数据达到百万、千万甚至更高规模，风险会进一步放大。

索引需要重建

排序规则变化会影响字符串的比较方式，因此相关字段的索引通常需要重新构建，例如：

  • 普通索引
  • 唯一索引
  • 联合索引

索引重建会带来额外的 I/O 和 CPU 消耗，在高负载系统中可能影响整体性能。

可能引发唯一索引冲突

如果字段从 大小写敏感 改为 大小写不敏感，原本合法的数据可能会出现冲突。

例如原始数据：

复制代码 
UserA
usera

在 utf8mb4_bin 下是合法的，但在 utf8mb4_unicode_ci 下会被认为是同一个值。

此时执行修改可能出现：

复制代码 
Duplicate entry

需要提前清理或合并数据。

查询行为可能发生变化

排序规则不仅影响存储，还会影响查询结果。

例如：

sql 复制代码 
SELECT * FROM users WHERE username LIKE 'abc%';

不同排序规则下结果不同：

排序规则 是否匹配 Abc
utf8mb4_bin 否
utf8mb4_unicode_ci 是

如果直接修改排序规则，部分业务查询结果可能发生变化。

可能导致乱码或转换失败

修改字符集时，如果原有数据编码与目标字符集不兼容，可能会出现乱码或转换失败的问题。

例如：

  • 原表使用 latin1
  • 数据实际存储的是 UTF-8 编码
  • 直接修改为 utf8mb4

可能出现以下问题：

  • 字符被错误转换导致乱码
  • 转换过程中出现非法字符
  • 修改操作报错中断

例如执行：

sql 复制代码 
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4;

如果数据存在非法编码，可能出现类似错误：

c 复制代码 
Incorrect string value

因此在修改字符集前通常需要：

  • 确认当前数据真实编码
  • 备份数据
  • 在测试环境验证转换结果

在复杂系统中，字符集问题往往不仅涉及数据库，还涉及：

  • 应用程序编码
  • JDBC / 连接字符串配置
  • 数据导入导出工具

如果处理不当，很容易导致系统出现乱码问题。

多表关联查询中字符集或排序规则不同导致索引失效

在多表关联查询中，如果连接字段（Join Key）的字符集或排序规则不同，即使两个字段都建立了索引，数据库在执行查询时仍然可能无法使用索引，从而导致全表扫描，严重影响查询性能。

例如，A 表和 B 表通过 name 字段进行关联：

sql 复制代码 
SELECT *
FROM table_a a
JOIN table_b b
ON a.name = b.name;

如果两个字段的定义如下：

scss 复制代码 
table_a.name VARCHAR(64) COLLATE utf8mb4_bin
table_b.name VARCHAR(64) COLLATE utf8mb4_unicode_ci

由于排序规则不同，数据库在比较字段值时需要进行字符集或排序规则转换。这种隐式转换会导致优化器无法使用已有索引，从而可能出现以下执行计划：

  • 关联字段索引失效
  • 使用全表扫描
  • 使用临时表或 filesort
  • 查询性能明显下降

在数据量较大的系统中，这类问题会显著放大，特别是在以下场景中：

  • 高频 JOIN 查询
  • 报表或统计类查询
  • 分页查询
  • 多表复杂关联查询

在 EXPLAIN 执行计划中，通常会表现为：

  • type 变为 ALL
  • possible_keys 存在但 key 为 NULL
  • rows 扫描数量显著增大

例如：

css 复制代码 
EXPLAIN
SELECT *
FROM table_a a
JOIN table_b b
ON a.name = b.name;

可能出现：

type key rows
ALL NULL 1000000

说明数据库没有使用索引，而是执行了全表扫描。

为了避免这种情况，数据库设计时应遵循以下规范：

连接字段应保持完全一致的定义，包括：

  • 字段类型一致（如 VARCHAR(64)）
  • 字符集一致（如 utf8mb4）
  • 排序规则一致（如 utf8mb4_bin）
  • 长度一致

例如：

sql 复制代码 
table_a.name VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin
table_b.name VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin

对于系统中的关联字段，通常建议：

  • 使用统一字符集（推荐 utf8mb4）
  • 使用大小写敏感排序规则（如 utf8mb4_bin）
  • 尽量使用语义明确、结构简单的字段（例如 ID、编码或 UUID）
  • 避免在 JOIN 条件中进行函数计算或类型转换

例如以下写法都会导致索引失效：

css 复制代码 
ON LOWER(a.name) = b.name
vbnet 复制代码 
ON a.name = CAST(b.name AS CHAR)

在数据库规范中，应特别强调 连接字段的结构统一性。一旦系统上线并积累大量数据，再去修改字符集或排序规则往往成本较高，因此应在设计阶段就统一规范。

如果系统已经存在字符集不一致的问题，通常需要通过以下方式进行治理：

  • 统一字段字符集和排序规则
  • 重建相关索引
  • 在新表设计时统一规范
  • 尽量避免使用字符串字段作为关联主键

对于高性能系统而言，关联字段优先使用数值型 ID（如 BIGINT） ，既可以避免字符集问题，也能获得更好的索引效率。

推荐的数据库设计规范

在实际项目中，可以通过制定数据库规范来减少后期修改的风险。

推荐的实践包括：

数据库默认字符集统一使用：

复制代码 
utf8mb4

数据库默认排序规则使用：

复制代码 
utf8mb4_0900_ai_ci

用户输入的自然语言字段使用不区分大小写的排序规则，例如：

复制代码 
utf8mb4_0900_ai_ci

技术标识符字段使用大小写敏感规则，例如：

复制代码 
utf8mb4_bin

例如：

sql 复制代码 
CREATE TABLE users (
    id BIGINT PRIMARY KEY,

    username VARCHAR(64) COLLATE utf8mb4_bin,

    email VARCHAR(128) COLLATE utf8mb4_0900_ai_ci,

    nickname VARCHAR(64) COLLATE utf8mb4_0900_ai_ci,

    password_hash VARCHAR(255) COLLATE utf8mb4_bin,

    api_key VARCHAR(128) COLLATE utf8mb4_bin
);

通过在设计阶段明确这些规则，可以避免在系统规模扩大后再进行高风险的结构调整。

小结

字符集和排序规则虽然看起来只是数据库的基础配置，但它们会影响：

  • 字符串比较逻辑
  • 索引行为
  • 查询结果
  • 系统性能
  • 数据编码正确性

因此在数据库设计阶段就应确定好相关规范，并在项目中统一执行。

一旦系统上线并积累大量数据，再修改这些属性往往需要付出较高成本，甚至可能影响线上业务稳定性。因此应尽量在设计阶段完成规划，而不是在生产环境中频繁调整。

总结

在 MySQL 8 中选择排序规则时，核心原则是根据字段语义进行设计。排序规则不仅影响字符串比较，还会影响索引、模糊查询和唯一约束。

技术标识符字段建议使用大小写敏感规则，例如：

复制代码 
utf8mb4_bin

用户输入文本建议使用大小写不敏感规则，例如：

复制代码 
utf8mb4_0900_ai_ci

数据库默认排序规则建议使用 utf8mb4_0900_ai_ci，并对特殊字段进行单独配置。

合理的排序规则设计不仅能避免后期迁移问题，也能提升搜索体验和查询效率。

当业务需求发生变化时，可以通过以下方式调整：

  • 修改字段排序规则
  • 新增指定排序规则字段
  • 修改表默认排序规则
  • 修改数据库默认排序规则

在生产环境执行这些操作前，应提前检查数据冲突和索引影响，以避免业务异常。

附录：不同数据规模修改字符集或排序规则的维护成本参考

在实际生产环境中，修改字符集或排序规则通常会触发表结构重建，因此会产生明显的维护成本。

以下表格是基于常见业务环境（普通 SSD、常规服务器配置、在线 DDL 未启用或不可用）的经验估算，仅作为容量规划和风险评估参考。

表数据规模 数据量级 典型维护耗时 锁表风险 建议策略
小表 < 10 万行 几秒 几乎无影响 可以直接修改
中小表 10 万 ~ 100 万 几秒 ~ 数十秒 低 低峰期执行
中型表 100 万 ~ 1000 万 数十秒 ~ 数分钟 中 需要评估业务窗口
大表 1000 万 ~ 1 亿 数分钟 ~ 数十分钟 较高 建议使用在线 DDL 或影子表迁移
超大表 > 1 亿 数十分钟 ~ 数小时 高 必须设计迁移方案

需要注意，实际耗时会受到以下因素影响：

  • 行数据大小（例如是否包含 TEXT/BLOB 字段）
  • 索引数量
  • 磁盘性能（SSD / NVMe / 网络存储）
  • MySQL 配置
  • 是否使用在线 DDL
  • 是否存在并发写入

例如执行如下操作：

sql 复制代码 
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

对于千万级数据表，很可能会触发表重建，并在执行过程中产生较长时间的 I/O 压力。

常见风险

修改字符集或排序规则时，可能出现以下问题：

风险类型 说明
锁表 元数据锁可能阻塞写入
索引重建 所有相关索引需要重新构建
查询性能波动 执行期间 I/O 压力上升
唯一索引冲突 大小写敏感规则变化导致冲突
数据乱码 原始数据编码与目标字符集不一致

生产环境建议

对于数据量较大的系统，一般建议采用更安全的迁移方式，例如：

  • 影子表迁移（Shadow Table）
  • 在线 DDL
  • 数据分批迁移
  • 使用中间层同步数据

例如通过以下流程进行迁移：

markdown 复制代码 
1. 创建新表（目标字符集）
2. 同步历史数据
3. 同步增量数据
4. 切换业务读写
5. 下线旧表

这种方式虽然步骤较多，但可以显著降低生产环境风险。

总体建议

字符集和排序规则属于数据库底层设计，一旦系统进入稳定运行阶段，大规模修改会带来较高维护成本。因此在系统设计阶段，应尽量提前规划好：

  • 默认字符集
  • 默认排序规则
  • 是否需要大小写敏感字段

通过前期规范化设计，可以避免后期在高数据量环境下进行高风险的结构调整。

相关推荐
七夜zippoe23 分钟前
OpenClaw 数据加密：敏感信息保护的完整方案
数据库·mysql·php·openclaw·敏感保护
万亿少女的梦16826 分钟前
基于Node.js和Express的旅游信息管理平台设计与开发
mysql·node.js·express·系统设计·旅游信息管理
万亿少女的梦16812 小时前
基于Python的高考志愿填报辅助系统设计与实现
java·spring boot·python·mysql·vue
万亿少女的梦16812 小时前
基于SpringBoot与Vue的历史博物馆展品展示与游客管理系统设计
spring boot·mysql·vue·系统设计·博物馆管理系统
灯澜忆梦14 小时前
MySQL 完整学习路线
学习·mysql
ClouGence14 小时前
保障公共安全，一线治安机构实时数据应用与实践
数据库·mysql·postgresql
Minxinbb15 小时前
TDSQL for MySQL 服务器重启操作
数据库·mysql·dba
渣渣灰飞16 小时前
MySQL 系统学习 第二阶段 第三章 DQL（Data Query Language）第三节：ORDER BY + LIMIT（排序 + 分页）
数据库·学习·mysql
fengbingchun18 小时前
客户端获取服务器端MySQL数据库表中数据C++实现
mysql
渣渣灰飞18 小时前
MySQL 系统学习 第二阶段 第三章 DQL（Data Query Language）第二节：WHERE 条件查询
sql·学习·mysql
热门推荐
01GitHub 镜像站点022026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf03AI科技热点日报 | 2026年07月01日04AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路05【AI】2026 年具身智能模型和世界模型总结062026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？072026 AI 编程工具选型横评：Cursor / Claude Code / Trae / Copilot 到底选谁（建议收藏·避坑版）082026 年 AI 大模型 & AI 编程工具实战全总结092026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片102026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？