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

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

2022-09-27 647
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
云数据库 RDS MySQL，集群系列 2核4GB
推荐场景：
搭建个人博客
云数据库 RDS MySQL，高可用系列 2核4GB
简介： 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 版分页优化
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL，然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
马丁玩编程
目录
相关文章
互联网课堂
|
9天前
|
SQL 关系型数据库 MySQL
深入解析MySQL的EXPLAIN：指标详解与索引优化
MySQL 中的 `EXPLAIN` 语句用于分析和优化 SQL 查询，帮助你了解查询优化器的执行计划。本文详细介绍了 `EXPLAIN` 输出的各项指标，如 `id`、`select_type`、`table`、`type`、`key` 等，并提供了如何利用这些指标优化索引结构和 SQL 语句的具体方法。通过实战案例，展示了如何通过创建合适索引和调整查询语句来提升查询性能。
互联网课堂
75 9
mikechen的互联网架构
|
1月前
|
SQL 关系型数据库 MySQL
大厂面试官：聊下 MySQL 慢查询优化、索引优化？
MySQL慢查询优化、索引优化，是必知必备，大厂面试高频，本文深入详解，建议收藏。关注【mikechen的互联网架构】，10年+BAT架构经验分享。
mikechen的互联网架构
150 0
大厂面试官：聊下 MySQL 慢查询优化、索引优化？
蓝易云
|
13天前
|
缓存 关系型数据库 MySQL
MySQL 索引优化以及慢查询优化
通过本文的介绍，希望您能够深入理解MySQL索引优化和慢查询优化的方法，并在实际应用中灵活运用这些技术，提升数据库的整体性能。
蓝易云
53 18
蓝易云
|
12天前
|
缓存 关系型数据库 MySQL
MySQL 索引优化以及慢查询优化
通过本文的介绍，希望您能够深入理解MySQL索引优化和慢查询优化的方法，并在实际应用中灵活运用这些技术，提升数据库的整体性能。
蓝易云
18 7
蓝易云
|
11天前
|
缓存 关系型数据库 MySQL
MySQL 索引优化与慢查询优化：原理与实践
通过本文的介绍，希望您能够深入理解MySQL索引优化与慢查询优化的原理和实践方法，并在实际项目中灵活运用这些技术，提升数据库的整体性能。
蓝易云
41 5
蓝易云
|
25天前
|
关系型数据库 MySQL PHP
php实现一个简单的MySQL分页
通过本文的详细步骤和代码示例，我们实现了一个简单的PHP MySQL分页功能。主要步骤包括计算总记录数、设置分页参数、查询当前页的数据以及生成分页链接。这种分页方式适用于大多数Web应用，能够有效提升用户体验和页面响应速度。
蓝易云
26 4
2G冲浪词条
|
24天前
|
SQL 关系型数据库 MySQL
mysql分页读取数据重复问题
在服务端开发中，与MySQL数据库进行数据交互时，常因数据量大、网络延迟等因素需分页读取数据。文章介绍了使用`limit`和`offset`参数实现分页的方法，并针对分页过程中可能出现的数据重复问题进行了详细分析，提出了利用时间戳或确保排序规则绝对性等解决方案。
2G冲浪词条
33 1
喜欢猪猪
|
1月前
|
关系型数据库 MySQL Java
MySQL索引优化与Java应用实践
【11月更文挑战第25天】在大数据量和高并发的业务场景下，MySQL数据库的索引优化是提升查询性能的关键。本文将深入探讨MySQL索引的多种类型、优化策略及其在Java应用中的实践，通过历史背景、业务场景、底层原理的介绍，并结合Java示例代码，帮助Java架构师更好地理解并应用这些技术。
喜欢猪猪
32 2
栈江湖
|
3天前
|
存储 Oracle 关系型数据库
数据库传奇：MySQL创世之父的两千金My、Maria
《数据库传奇：MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建，现归Oracle所有，广泛应用于阿里巴巴、腾讯等企业。2009年，Widenius因担心Oracle收购影响MySQL的开源性，创建了MariaDB，提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB，以确保更好的性能和社区支持。掌握MariaDB作为备用方案，对未来发展至关重要。
栈江湖
13 3
栈江湖
|
3天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱：探秘Redo/Undo日志确保数据库安全无忧！
《MySQL崩溃保险箱：探秘Redo/Undo日志确保数据库安全无忧！》介绍了MySQL中的三种关键日志：二进制日志（Binary Log）、重做日志（Redo Log）和撤销日志（Undo Log）。这些日志确保了数据库的ACID特性，即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改，保证事务持久性；Undo Log记录事务的逆操作，支持回滚和多版本并发控制（MVCC）。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异，强调了InnoDB在高并发和事务处理中的优势。通过这些机制，MySQL能够在事务执行、崩溃和恢复过程中保持
栈江湖
19 3

热门文章

最新文章

  • 1
    MySQL数据库下载安装教程（Windows&Linux）
  • 2
    MySQL常用函数：IF、SUM等用法
  • 3
    Python处理数据库：MySQL与SQLite详解 | python小知识
  • 4
    从新手到高手：彻底掌握MySQL表死锁
  • 5
    MySQL事务隔离级别及默认隔离级别的设置
  • 6
    Liunx部署java项目Tomcat、Redis、Mysql教程
  • 7
    Mysql索引：深入理解InnoDb聚集索引与MyisAm非聚集索引
  • 8
    MySQL导入.sql文件后数据库乱码问题
  • 9
    MySQL的插件式认证到底是干什么的？
  • 10
    数据库数据恢复—MYSQL数据库文件损坏的数据恢复案例
  • 1
    Java医院绩效考核系统源码B/S+avue+MySQL助力医院实现精细化管理
    82
  • 2
    Linux对MySQL语法校验
    93
  • 3
    【MySQL系列笔记】分库分表
    226
  • 4
    mysql 设置环境变量与未设置环境变量连接数据库的区别
    169
  • 5
    服务器Linux系统配置mysql数据库主从自动备份
    218
  • 6
    mysqlTools 一分钟部署安装本mysql多个版本，解锁繁琐部署过程
    420
  • 7
    golang使用gorm操作mysql3，数据查询
    97
  • 8
    golang使用gorm操作mysql2
    68
  • 9
    golang使用gorm操作mysql1
    116
  • 10
    Hbase与MySQL对比，区别是什么？
    324

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • One Box： 解读事务与分析一体化数据库 HybridDB for MySQL
  • One Box：解读事务与分析一体化数据库HybridDB for MySQL
  • 如何支撑HTAP场景-HybridDB for MySQL系统架构和技术演进

    • 相关实验场景

    更多
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • 5分钟上手Flink MySQL连接器
  • 云端MySQL的安装及应用
  • 手动部署MySQL数据库（Alibaba Cloud Linux 2）
  • 手动部署MySQL数据库（CentOS 7）

    • 推荐镜像

    更多
  • mysql
  • mariadb
  • postgresql
    • 下一篇
    DataWorks售前咨询