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

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

2022-09-27 596
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
云数据库 RDS MySQL，集群版 2核4GB 100GB
推荐场景：
搭建个人博客
云数据库 RDS MySQL，高可用版 2核4GB 50GB
简介： 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 版数据量优化
相关实践学习
如何在云端创建MySQL数据库
开始实验后，系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
马丁玩编程
目录
相关文章
aliyun7689123603-22772
|
17天前
|
关系型数据库 MySQL 数据库
mysql数据量很大的数据库迁移最优的方案 原创
8月更文挑战第2天
aliyun7689123603-22772
73 7
小王老师呀
|
2天前
|
存储 关系型数据库 MySQL
mysql数据库查询时用到的分页方法有哪些
【8月更文挑战第16天】在MySQL中，实现分页的主要方法包括：1）使用`LIMIT`子句，简单直接但随页数增加性能下降；2）通过子查询优化`LIMIT`分页，提高大页码时的查询效率；3）利用存储过程封装分页逻辑，便于复用但需额外维护；4）借助MySQL变量实现，可能提供更好的性能但实现较复杂。这些方法各有优缺点，可根据实际需求选择适用方案。
小王老师呀
10 1
蓝易云
|
6天前
|
存储 算法 关系型数据库
探索MySQL递归查询，优雅的给树结构分页!
总结起来，对于MySQL中的树结构数据，递归查询结合预排序遍历树算法可以实现优雅的分页，但需要注意性能优化和数据更新的问题。这项技术提供了一种高效处理层级数据的工具，使得开发者可以在复杂的数据结构下实现直观和可靠的数据查询。
蓝易云
15 1
蓝易云
|
6天前
|
SQL 关系型数据库 MySQL
MySQL】-DQL（基本、条件、分组、排序、分页）详细版
通过这些查询方法，你可以高效地检索、分析和组织MySQL数据库中的数据，以满足各种应用需求。实践中，理解这些SQL语句的基础知识以及它们如何组合起来进行复杂的数据操作是至关重要的。
蓝易云
15 1
最好zzz
|
8天前
|
存储 关系型数据库 MySQL
MySQL 上亿大表，如何深度优化？
【8月更文挑战第11天】随着大数据时代的到来，MySQL 作为广泛使用的关系型数据库管理系统，经常需要处理上亿级别的数据。当数据量如此庞大时，如何确保数据库的查询效率、稳定性和可扩展性，成为了一个亟待解决的问题。本文将围绕 MySQL 上亿大表的深度优化，分享一系列实用的技术干货，帮助你在工作和学习中应对挑战。
最好zzz
23 1
竹子爱熊猫
|
18天前
|
SQL canal 关系型数据库
(二十四)全解MySQL之主从篇：死磕主从复制中数据同步原理与优化
兜兜转转，经过《全解MySQL专栏》前面二十多篇的内容讲解后，基本对MySQL单机模式下的各方面进阶知识做了详细阐述，同时在前面的《分库分表概念篇》、《分库分表隐患篇》两章中也首次提到了数据库的一些高可用方案，但前两章大多属于方法论，并未涵盖真正的实操过程。接下来的内容，会以目前这章作为分割点，开启MySQL高可用方案的落地实践分享的新章程！
竹子爱熊猫
113 1
william.zhang(张)
|
2天前
|
存储 SQL 关系型数据库
探索MySQL的执行奥秘：从查询执行到数据存储与优化的深入解析
探索MySQL的执行奥秘：从查询执行到数据存储与优化的深入解析
william.zhang(张)
9 0
李木子2024
|
10天前
|
运维 关系型数据库 MySQL
"MySQL运维精髓：深入解析数据库及表的高效创建、管理、优化与备份恢复策略"
【8月更文挑战第9天】MySQL是最流行的开源数据库之一，其运维对数据安全与性能至关重要。本文通过最佳实践介绍数据库及表的创建、管理与优化，包括示例代码。涵盖创建/删除数据库、表结构定义/调整、索引优化和查询分析，以及数据备份与恢复等关键操作，助您高效管理MySQL，确保数据完整性和系统稳定运行。
李木子2024
24 0
花酒锄作田
|
12天前
|
SQL 缓存 关系型数据库
MySQL配置简单优化与读写测试
MySQL配置简单优化与读写测试
花酒锄作田
21 0
游客lkw7toijkbadm
|
22天前
|
分布式计算 关系型数据库 MySQL
MySQL超时参数优化与DataX高效数据同步实践
通过合理设置MySQL的超时参数，可以有效地提升数据库的稳定性和性能。而DataX作为一种高效的数据同步工具，可以帮助企业轻松实现不同数据源之间的数据迁移。无论是优化MySQL参数还是使用DataX进行数据同步，都需要根据具体的应用场景来进行细致的配置和测试，以达到最佳效果。
游客lkw7toijkbadm
78 0

热门文章

最新文章

  • 1
    RDS for SQL server 空间问题排查汇总
  • 2
    PolarDB MySQL 5.7/RDS 5.7升级到PolarDB MySQL 8.0最佳实践
  • 3
    收集的mysql热复制的资料与常用语句
  • 4
    【转】源码安装Mysql，补装innodb引擎方法
  • 5
    mysql5.6 主从
  • 6
    mysql存储过程
  • 7
    修改MYSQL登录密码
  • 8
    openStack云平台虚拟桌面galera mysql 3节点集群实例实战 调试完成
  • 9
    MySQL Events学习笔记
  • 10
    MySQL学习笔记--索引的创建，删除
  • 1
    自动化备份MySQL数据库并上传到远程FTP服务器
    87
  • 2
    DataWorks操作报错合集之DataWorks在同步mysql时报错Code:[Framework-02]，mysql里面有个json类型字段，是什么原因导致的
    87
  • 3
    【Go语言专栏】使用Go语言连接MySQL数据库
    766
  • 4
    DataWorks产品使用合集之在DataWorks中，如何通过PolarDB for MySQL来查看binlog日志
    74
  • 5
    datagrip连接mysql报错： No appropriate protocol (protocol is disabled or cipher suites are inappropriate
    63
  • 6
    Ubuntu 20.04 + mysql8 安装以及配置大小写不敏感
    259
  • 7
    DataWorks产品使用合集之DataWorks还有就是对于mysql中的表已经存在数据了，第一次全量后面增量同步的步骤如何解决
    53
  • 8
    centos7在线安装jdk1.8+tomcat+mysql8+nginx+docker
    348
  • 9
    DataWorks产品使用合集之在DataWorks中，将数据集成功能将AnalyticDB for MySQL中的数据实时同步到MaxCompute中如何解决
    57
  • 10
    DataWorks产品使用合集之在DataWorks中，将ODPS数据导入到MySQL的步骤如何解决
    62

    • 相关课程

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

    • 相关电子书

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

    • 相关实验场景

    更多
  • MySQL基础-学生管理系统数据库设计
  • 如何快速连接云数据库RDS MySQL
  • MySQL数据库快速部署实践
  • MyBase MySQL实例资源灵活弹配
  • RDS MySQL大促场景下的智能化弹性
  • 如何开通MySQL的专属集群

    • 推荐镜像

    更多
  • mysql
  • postgresql
  • mariadb
    • 下一篇
    通义千问API入门教程