AI 助理
文档备案控制台
开发者社区 数据库 文章 正文

MySQL 千万数据量深分页优化, 拒绝线上故障！

2022-09-27 999
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL DuckDB 分析主实例，基础系列 4核8GB
RDS Agent（兼容OpenClaw），2核4GB
RDS DuckDB + QuickBI 企业套餐，8核32GB + QuickBI 专业版
简介： MySQL 千万数据量深分页优化, 拒绝线上故障！

在这里插入图片描述

前言

优化项目代码过程中发现一个千万级数据深分页问题，缘由是这样的

库里有一张耗材 MCS_PROD 表，通过同步外部数据中台多维度数据，在系统内部组装为单一耗材产品，最终同步到 ES 搜索引擎

MySQL 同步 ES 流程如下：

  1. 通过定时任务的形式触发同步，比如间隔半天或一天的时间频率
  2. 同步的形式为增量同步，根据更新时间的机制，比如第一次同步查询 >= 1970-01-01 00:00:00.0
  3. 记录最大的更新时间进行存储，下次更新同步以此为条件
  4. 以分页的形式获取数据，当前页数量加一，循环到最后一页

在这里问题也就出现了，MySQL 查询分页 OFFSET 越深入，性能越差，初步估计线上 MCS_PROD 表中记录在 1000w 左右

如果按照每页 10 条，OFFSET 值会拖垮查询性能，进而形成一个 "性能深渊"

同步类代码针对此问题有两种优化方式：

  1. 采用游标、流式方案进行优化
  2. 优化深分页性能，文章围绕这个题目展开

文章目录如下：

  • 软硬件说明
  • 重新认识 MySQL 分页

  • 深分页优化

    • 子查询优化
    • 延迟关联
    • 书签记录

    • ORDER BY 巨坑，慎踩

      • ORDER BY 索引失效举例
    • 结言

软硬件说明

MySQL VERSION

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.7.30    |
+-----------+
1 row in set (0.01 sec)

表结构说明

借鉴公司表结构，字段、长度以及名称均已删减

mysql> DESC MCS_PROD;
+-----------------------+--------------+------+-----+---------+----------------+
| Field                 | Type         | Null | Key | Default | Extra          |
+-----------------------+--------------+------+-----+---------+----------------+
| MCS_PROD_ID_A         | int(11)      | NO   | PRI | NULL    | auto_increment |
| MCS_CODE_B            | varchar(100) | YES  |     |         |                |
| MCS_NAME_C            | varchar(500) | YES  |     |         |                |
| UPDT_TIME             | datetime     | NO   | MUL | NULL    |                |
+-----------------------+--------------+------+-----+---------+----------------+
4 rows in set (0.01 sec)

通过测试同学帮忙造了 500w 左右数据量

mysql> SELECT COUNT(*) FROM MCS_PROD;
+----------+
| count(*) |
+----------+
|  5100000 |
+----------+
1 row in set (1.43 sec)

SQL 语句如下

因为功能需要满足 增量拉取的方式，所以会有数据更新时间的条件查询，以及相关 查询排序（此处有坑）

SELECT
    MCS_PROD_ID_A,
    MCS_CODE_B,
    MCS_NAME_C,
    UPDT_TIME
FROM
    MCS_PROD
WHERE
    UPDT_TIME >= '1970-01-01 00:00:00.0' ORDER BY UPDT_TIME
LIMIT xx, xx

重新认识 MySQL 分页

LIMIT 子句可以被用于强制 SELECT 语句返回指定的记录数。LIMIT 接收一个或两个数字参数，参数必须是一个整数常量

如果给定两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数

微信搜索【源码兴趣圈】，关注龙台，回复【资料】领取涵盖 GO、Netty、SpringCLoud Alibaba、Seata、开发规范、面试宝典、数据结构等电子书 or 视频学习资料！

举个简单的例子，分析下 SQL 查询过程，掌握深分页性能为什么差

mysql> SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C FROM MCS_PROD WHERE (UPDT_TIME >= '1970-01-01 00:00:00.0') ORDER BY UPDT_TIME LIMIT 100000, 1;
+---------------+-------------------------+------------------+---------------------+
| MCS_PROD_ID_A | MCS_CODE_B              | MCS_NAME_C       | UPDT_TIME           |
+---------------+-------------------------+------------------+---------------------+
|      181789   | XA601709733186213015031 | 尺、桡骨LC-DCP骨板 | 2020-10-19 16:22:19 |
+---------------+-------------------------+------------------+---------------------+
1 row in set (3.66 sec)

mysql> EXPLAIN SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C FROM MCS_PROD WHERE (UPDT_TIME >= '1970-01-01 00:00:00.0') ORDER BY UPDT_TIME LIMIT 100000, 1;
+----+-------------+----------+------------+-------+---------------+------------+---------+------+---------+----------+-----------------------+
| id | select_type | table    | partitions | type  | possible_keys | key        | key_len | ref  | rows    | filtered | Extra                 |
+----+-------------+----------+------------+-------+---------------+------------+---------+------+---------+----------+-----------------------+
|  1 | SIMPLE      | MCS_PROD | NULL       | range | MCS_PROD_1    | MCS_PROD_1 | 5       | NULL | 2296653 |   100.00 | Using index condition |
+----+-------------+----------+------------+-------+---------------+------------+---------+------+---------+----------+-----------------------+
1 row in set, 1 warning (0.01 sec)

简单说明下上面 SQL 执行过程：

  1. 首先查询了表 MCS_PROD，进行过滤 UPDT_TIME 条件，查询出展示列（涉及回表操作）进行排序以及 LIMIT
  2. LIMIT 100000, 1 的意思是扫描满足条件的 100001 行，然后扔掉前 100000 行

MySQL 耗费了 大量随机 I/O 在回表查询聚簇索引的数据上，而这 100000 次随机 I/O 查询数据不会出现在结果集中

如果系统并发量稍微高一点，每次查询扫描超过 100000 行，性能肯定堪忧，另外 LIMIT 分页 OFFSET 越深，性能越差（多次强调）

图1 数据仅供参考

深分页优化

关于 MySQL 深分页优化常见的大概有以下三种策略：

  1. 子查询优化
  2. 延迟关联
  3. 书签记录

上面三点都能大大的提升查询效率，核心思想就是让 MySQL 尽可能扫描更少的页面，获取需要访问的记录后再根据关联列回原表查询所需要的列

子查询优化

子查询深分页优化语句如下：

mysql> SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C FROM MCS_PROD WHERE MCS_PROD_ID >= ( SELECT m1.MCS_PROD_ID_A FROM MCS_PROD m1 WHERE m1.UPDT_TIME >= '1970-01-01 00:00:00.0' ORDER BY m1.UPDT_TIME LIMIT 3000000, 1) LIMIT 1;
+---------------+-------------------------+------------------------+
| MCS_PROD_ID_A | MCS_CODE_B              | MCS_NAME_C             |
+---------------+-------------------------+------------------------+
|     3021401   | XA892010009391491861476 | 金属解剖型接骨板T型接骨板A |
+---------------+-------------------------+------------------------+
1 row in set (0.76 sec)

mysql> EXPLAIN SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C FROM MCS_PROD WHERE MCS_PROD_ID_A >= ( SELECT m1.MCS_PROD_ID_A FROM MCS_PROD m1 WHERE m1.UPDT_TIME >= '1970-01-01 00:00:00.0' ORDER BY m1.UPDT_TIME LIMIT 3000000, 1) LIMIT 1;
+----+-------------+----------+------------+-------+---------------+------------+---------+------+---------+----------+--------------------------+
| id | select_type | table    | partitions | type  | possible_keys | key        | key_len | ref  | rows    | filtered | Extra                    |
+----+-------------+----------+------------+-------+---------------+------------+---------+------+---------+----------+--------------------------+
|  1 | PRIMARY     | MCS_PROD | NULL       | range | PRIMARY       | PRIMARY    | 4       | NULL | 2296653 |   100.00 | Using where              |
|  2 | SUBQUERY    | m1       | NULL       | range | MCS_PROD_1    | MCS_PROD_1 | 5       | NULL | 2296653 |   100.00 | Using where; Using index |
+----+-------------+----------+------------+-------+---------------+------------+---------+------+---------+----------+--------------------------+
2 rows in set, 1 warning (0.77 sec)

根据执行计得知，子查询 table m1 查询是用到了索引。首先在 索引上拿到了聚集索引的主键 ID 省去了回表操作，然后第二查询直接根据第一个查询的 ID 往后再去查 10 个就可以了

图2 数据仅供参考

延迟关联

"延迟关联" 深分页优化语句如下：

mysql> SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C FROM MCS_PROD INNER JOIN (SELECT m1.MCS_PROD_ID_A FROM MCS_PROD m1 WHERE m1.UPDT_TIME >= '1970-01-01 00:00:00.0' ORDER BY m1.UPDT_TIME LIMIT 3000000, 1) AS  MCS_PROD2 USING(MCS_PROD_ID_A);
+---------------+-------------------------+------------------------+
| MCS_PROD_ID_A | MCS_CODE_B              | MCS_NAME_C             |
+---------------+-------------------------+------------------------+
|     3021401   | XA892010009391491861476 | 金属解剖型接骨板T型接骨板A |
+---------------+-------------------------+------------------------+
1 row in set (0.75 sec)

mysql> EXPLAIN SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C FROM MCS_PROD INNER JOIN (SELECT m1.MCS_PROD_ID_A FROM MCS_PROD m1 WHERE m1.UPDT_TIME >= '1970-01-01 00:00:00.0' ORDER BY m1.UPDT_TIME LIMIT 3000000, 1) AS  MCS_PROD2 USING(MCS_PROD_ID);
+----+-------------+------------+------------+--------+---------------+------------+---------+-----------------------+---------+----------+--------------------------+
| id | select_type | table      | partitions | type   | possible_keys | key        | key_len | ref                   | rows    | filtered | Extra                    |
+----+-------------+------------+------------+--------+---------------+------------+---------+-----------------------+---------+----------+--------------------------+
|  1 | PRIMARY     | <derived2> | NULL       | ALL    | NULL          | NULL       | NULL    | NULL                  | 2296653 |   100.00 | NULL                     |
|  1 | PRIMARY     | MCS_PROD   | NULL       | eq_ref | PRIMARY       | PRIMARY    | 4       | MCS_PROD2.MCS_PROD_ID |       1 |   100.00 | NULL                     |
|  2 | DERIVED     | m1         | NULL       | range  | MCS_PROD_1    | MCS_PROD_1 | 5       | NULL                  | 2296653 |   100.00 | Using where; Using index |
+----+-------------+------------+------------+--------+---------------+------------+---------+-----------------------+---------+----------+--------------------------+
3 rows in set, 1 warning (0.00 sec)

思路以及性能与子查询优化一致，只不过采用了 JOIN 的形式执行

书签记录

关于 LIMIT 深分页问题，核心在于 OFFSET 值，它会 导致 MySQL 扫描大量不需要的记录行然后抛弃掉

我们可以先使用书签 记录获取上次取数据的位置，下次就可以直接从该位置开始扫描，这样可以 避免使用 OFFEST

假设需要查询 3000000 行数据后的第 1 条记录，查询可以这么写

mysql> SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C FROM MCS_PROD WHERE MCS_PROD_ID_A < 3000000 ORDER BY UPDT_TIME LIMIT 1;
+---------------+-------------------------+---------------------------------+
| MCS_PROD_ID_A | MCS_CODE_B              | MCS_NAME_C                      |
+---------------+-------------------------+---------------------------------+
|         127   | XA683240878449276581799 | 股骨近端-1螺纹孔锁定板（纯钛）YJBL01 |
+---------------+-------------------------+---------------------------------+
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C FROM MCS_PROD WHERE MCS_PROD_ID_A < 3000000 ORDER BY UPDT_TIME LIMIT 1;
+----+-------------+----------+------------+-------+---------------+------------+---------+------+------+----------+-------------+
| id | select_type | table    | partitions | type  | possible_keys | key        | key_len | ref  | rows | filtered | Extra       |
+----+-------------+----------+------------+-------+---------------+------------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | MCS_PROD | NULL       | index | PRIMARY       | MCS_PROD_1 | 5       | NULL |    2 |    50.00 | Using where |
+----+-------------+----------+------------+-------+---------------+------------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

好处是很明显的，查询速度超级快，性能都会稳定在毫秒级，从性能上考虑碾压其它方式

不过这种方式局限性也比较大，需要一种类似连续自增的字段，以及业务所能包容的连续概念，视情况而定

上图是阿里云 OSS Bucket 桶内文件列表，大胆猜测是不是可以采用书签记录的形式完成

ORDER BY 巨坑, 慎踩

以下言论可能会打破你对 order by 所有 美好 YY

先说结论吧，当 LIMIT OFFSET 过深时，会使 ORDER BY 普通索引失效（联合、唯一这些索引没有测试）

mysql> EXPLAIN SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C,UPDT_TIME FROM MCS_PROD WHERE (UPDT_TIME >= '1970-01-01 00:00:00.0') ORDER BY UPDT_TIME LIMIT 100000, 1;
+----+-------------+----------+------------+-------+---------------+------------+---------+------+---------+----------+-----------------------+
| id | select_type | table    | partitions | type  | possible_keys | key        | key_len | ref  | rows    | filtered | Extra                 |
+----+-------------+----------+------------+-------+---------------+------------+---------+------+---------+----------+-----------------------+
|  1 | SIMPLE      | MCS_PROD | NULL       | range | MCS_PROD_1    | MCS_PROD_1 | 5       | NULL | 2296653 |   100.00 | Using index condition |
+----+-------------+----------+------------+-------+---------------+------------+---------+------+---------+----------+-----------------------+
1 row in set, 1 warning (0.00 sec)

先来说一下这个 ORDER BY 执行过程：

  1. 初始化 SORT_BUFFER，放入 MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C,UPDT_TIME 四个字段
  2. 从索引 UPDT_TIME 找到满足条件的主键 ID，回表查询出四个字段值存入 SORT_BUFFER
  3. 从索引处继续查询满足 UPDT_TIME 条件记录，继续执行步骤 2
  4. 对 SORT_BUFFER 中的数据按照 UPDT_TIME 排序
  5. 排序成功后取出符合 LIMIT 条件的记录返回客户端

按照 UPDT_TIME 排序可能在内存中完成，也可能需要使用外部排序，取决于排序所需的内存和参数 SORT_BUFFER_SIZE

SORT_BUFFER_SIZE 是 MySQL 为排序开辟的内存。如果排序数据量小于 SORT_BUFFER_SIZE，排序会在内存中完成。如果数据量过大，内存放不下，则会利用磁盘临时文件排序

针对 SORT_BUFFER_SIZE 这个参数在网上查询到有用资料比较少，大家如果测试过程中存在问题，可以加微信一起沟通

ORDER BY 索引失效举例

OFFSET 100000 时，通过 key Extra 得知，没有使用磁盘临时文件排序，这个时候把 OFFSET 调整到 500000

凉凉夜色为你思念成河，化作春泥呵护着你... 一首凉凉送给写这个 SQL 的同学，发现了 Using filesort

mysql> EXPLAIN SELECT MCS_PROD_ID_A,MCS_CODE_B,MCS_NAME_C,UPDT_TIME FROM MCS_PROD WHERE (UPDT_TIME >= '1970-01-01 00:00:00.0') ORDER BY UPDT_TIME LIMIT 500000, 1;
+----+-------------+----------+------------+------+---------------+------+---------+------+---------+----------+-----------------------------+
| id | select_type | table    | partitions | type | possible_keys | key  | key_len | ref  | rows    | filtered | Extra                       |
+----+-------------+----------+------------+------+---------------+------+---------+------+---------+----------+-----------------------------+
|  1 | SIMPLE      | MCS_PROD | NULL       | ALL  | MCS_PROD_1    | NULL | NULL    | NULL | 4593306 |    50.00 | Using where; Using filesort |
+----+-------------+----------+------------+------+---------------+------+---------+------+---------+----------+-----------------------------+
1 row in set, 1 warning (0.00 sec)

Using filesort 表示在索引之外，需要额外进行外部的排序动作，性能必将受到严重影响

所以我们应该 结合相对应的业务逻辑避免常规 LIMIT OFFSET，采用 # 深分页优化 章节进行修改对应业务

结言

最后有一点需要声明下，MySQL 本身并不适合单表大数据量业务

因为 MySQL 应用在企业级项目时，针对库表查询并非简单的条件，可能会有更复杂的联合查询，亦或者是大数据量时存在频繁新增或更新操作，维护索引或者数据 ACID 特性上必然存在性能牺牲

如果设计初期能够预料到库表的数据增长，理应构思合理的重构优化方式，比如 ES 配合查询、分库分表、TiDB 等解决方式

文章标签：
云数据库 RDS MySQL 版
Go
搜索推荐
SQL
关系型数据库
索引
对象存储
SpringCloudAlibaba
MySQL
存储
关键词：
云数据库 RDS MySQL 版优化
云数据库 RDS MySQL 版分页优化
云数据库 RDS MySQL 版分页
云数据库 RDS MySQL 版数据量
云数据库 RDS MySQL 版数据量优化
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发，帮助IT从业者们通过“阿里云Web应用上云解决方案”，了解一个企业级Web应用上云的常见架构，了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品：云数据库RDS MySQL 版 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务，提供容灾、备份、恢复、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
马丁玩编程
目录
相关文章
运营研究坊
|
11月前
|
SQL 缓存 关系型数据库
MySQL 慢查询是怎样优化的
本文深入解析了MySQL查询速度变慢的原因及优化策略，涵盖查询缓存、执行流程、SQL优化、执行计划分析（如EXPLAIN）、查询状态查看等内容，帮助开发者快速定位并解决慢查询问题。
运营研究坊
436 0
蓝易云
|
9月前
|
缓存 关系型数据库 MySQL
降低MySQL高CPU使用率的优化策略。
通过上述方法不断地迭代改进，在实际操作中需要根据具体场景做出相对合理判断。每一步改进都需谨慎评估其变动可能导致其他方面问题，在做任何变动前建议先在测试环境验证其效果后再部署到生产环境中去。
蓝易云
370 6
Unfailed_realme
|
10月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分，阐述了 char 与 varchar 在存储方式和性能上的差异，以及事务的 ACID 特性、并发事务问题及对应的隔离级别（MySQL 默认 REPEATABLE READ）。 索引基础部分，详解了 InnoDB 默认的 B+tree 索引结构（多路平衡树、叶子节点存数据、双向链表支持区间查询），区分了聚簇索引（数据与索引共存，唯一）和二级索引（数据与索引分离，多个），解释了回表查询的概念及优化方法，并分析了 B+tree 作为索引结构的优势（树高低、效率稳、支持区间查询）。 索引优化部分，列出了索引创建的六大原则
Unfailed_realme
268 2
技术自由圈/原疯狂创客圈
|
存储 SQL 关系型数据库
京东面试：mysql深度分页 严重影响性能？根本原因是什么？如何优化？
京东面试：mysql深度分页 严重影响性能？根本原因是什么？如何优化？
技术自由圈/原疯狂创客圈
731 8
京东面试：mysql深度分页 严重影响性能？根本原因是什么？如何优化？
青云@yd
|
10月前
|
存储 SQL 关系型数据库
MySQL 动态分区管理：自动化与优化实践
本文介绍了如何利用 MySQL 的存储过程与事件调度器实现动态分区管理，自动化应对数据增长，提升查询性能与数据管理效率，并详细解析了分区创建、冲突避免及实际应用中的关键注意事项。
青云@yd
442 0
蓝易云
|
存储 关系型数据库 MySQL
MySQL细节优化：关闭大小写敏感功能的方法。
通过这种方法，你就可以成功关闭 MySQL 的大小写敏感功能，让你的数据库操作更加便捷。
蓝易云
1117 19
蓝易云
|
SQL 关系型数据库 MySQL
基于SQL Server / MySQL进行百万条数据过滤优化方案
对百万级别数据进行高效过滤查询，需要综合使用索引、查询优化、表分区、统计信息和视图等技术手段。通过合理的数据库设计和查询优化，可以显著提升查询性能，确保系统的高效稳定运行。
蓝易云
833 9
顾翔
|
8月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能（下）
使用MYSQL Report分析数据库性能
顾翔
536 158
翼龙云TG_yilongcloud
|
8月前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程，需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS，可快速、平滑完成迁移任务，将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例，实现间接迁移上云。
翼龙云TG_yilongcloud
293 1
游客vphb4ae2je2zi
|
8月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格：MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB，多种引擎优惠上线！MySQL倚天版88元/年，SQL Server 2核4G仅299元/年，PostgreSQL 227元/年起。高可用、可弹性伸缩，安全稳定。详情见官网活动页。
游客vphb4ae2je2zi
1423 152

热门文章

最新文章

  • 1
    阿里云DTS踩坑经验分享系列｜如何使用DTS进行MySQL->ClickHouse同步
  • 2
    MySQL · 引擎特性 · InnoDB redo log漫游
  • 3
    阿里云服务器ecs配置之安装mysql
  • 4
    运维工程师面试题总结-MySQL企业级实战及集群架构07
  • 5
    MySQL：使用mysqldump在Windows数据库定时备份
  • 6
    十二、MySQL用户管理
  • 7
    监控mysql状态的脚本
  • 8
    Percona Server 5.6 （数据库MySQL用户配置和数据库用户权限配置）
  • 9
    PHP调用MYSQL存储过程实例
  • 10
    Linux下MySQL 5.5的修改字符集编码为UTF8（彻底解决中文乱码问题）
  • 1
    Java语言与MySQL数据库连接的技术性探讨
    307
  • 2
    项目从 MySQL 切换 PostgreSQL，踩了太多的坑！！！
    1457
  • 3
    mysql 故障排除与优化
    305
  • 4
    mysql 主从复制与读写分离
    503
  • 5
    mysql 高阶语句 与视图
    334
  • 6
    mysql日志管理 、备份与恢复
    410
  • 7
    mysql 存储引擎 基本介绍
    244
  • 8
    mysql 事务基本介绍
    259
  • 9
    mysql 索引基本介绍
    236
  • 10
    mysql 数据库 增删改查 基本操作
    395

    • 相关课程

    更多
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 阿里云数据库产品家族及特性
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布
  • 阿里云MySQL云数据库产品体系介绍
  • One Box： 解读事务与分析一体化数据库 HybridDB for MySQL

    • 推荐镜像

    更多
  • mysql
    • 下一篇
    阿里云正式发布 Agentic 代码安全：AI驱动的双Agent协同引擎