智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座 -

2025年8月17日

MySQL高级讲座篇之：`ClickHouse`和`MySQL`的协同：如何构建`OLAP`和`OLTP`混合架构？

嘿，大家好！欢迎来到今天的MySQL高级讲座。今天我们要聊点刺激的，把MySQL和ClickHouse这两位性格迥异的大佬凑到一起，搞一个OLAP和OLTP混合架构。这就像把一个擅长短跑的选手和一个擅长马拉松的选手组成接力队，听起来有点疯狂，但效果绝对让你惊艳！第一部分：两位主角的性格分析在正式开始之前，我们先来了解一下这两位主角的性格特点，这样才能更好地理解为什么要让他们“联姻”。 MySQL：身经百战的老兵 MySQL，数据库界的常青树，就像你家门口的便利店，随处可见，用起来顺手。它是一个典型的OLTP（Online Transaction Processing）数据库，擅长处理高并发、低延迟的事务性操作。想象一下电商网站的下单、支付，银行系统的转账，这些都是MySQL的拿手好戏。优点：事务支持： ACID特性，保证数据的一致性和可靠性。成熟稳定：经过长时间的考验，Bug相对较少。生态完善：周边工具和技术栈非常丰富。易于上手：学习曲线平缓，容易掌握。缺点：分析能力弱：处理海量数据的复杂查询性能较差。扩展性有限：垂直扩展容易遇到瓶颈。并发写入性能瓶颈： …

继续阅读“MySQL高级讲座篇之：`ClickHouse`和`MySQL`的协同：如何构建`OLAP`和`OLTP`混合架构？”

2025年8月17日

MySQL高级讲座篇之：如何利用`Docker`和`Compose`快速搭建一个MySQL集群？

各位观众老爷，大家好！今天咱们不聊风花雪月，就来点硬核的——用 Docker 和 Compose 快速搭建 MySQL 集群。保证让你们听完，感觉自己也能瞬间变身 DBA！一、为啥要用 Docker 和 Compose 整 MySQL 集群？传统的 MySQL 集群搭建，那叫一个酸爽！各种配置、各种依赖，搞不好折腾个几天几夜才能搞定。而且，环境还容易出问题，比如版本冲突、配置不对等等。但是！有了 Docker 和 Compose，这一切都变得 So Easy！隔离性好：每个 MySQL 实例都运行在独立的 Docker 容器里，互不干扰。环境一致：不管你在 Windows、Mac 还是 Linux 上，只要有 Docker，环境就一样。告别“在我电脑上能跑”的魔咒！快速部署：一条 docker-compose up 命令，整个集群就起来了。易于扩展：想加几个节点？改改 Compose 文件，再执行一条命令就搞定。方便管理： Docker 提供了一整套管理工具，监控、日志、重启都很方便。二、集群架构：选哪个姿势最舒服？ MySQL 集群有很多种架构，比如主从复制 …

继续阅读“MySQL高级讲座篇之：如何利用`Docker`和`Compose`快速搭建一个MySQL集群？”

2025年8月17日

MySQL高级讲座篇之：如何利用`GTID`的`AUTO_POSITION`功能，实现无损故障切换？

各位观众老爷们，大家好！今天咱们来聊聊 MySQL 的 GTID 里的一个大杀器：AUTO_POSITION，看看它怎么帮你实现无损故障切换，让你的数据库像钢铁侠一样坚挺。一、GTID 是个啥玩意儿？首先，得知道 GTID (Global Transaction ID) 是什么。简单来说，它就像给每个事务贴了个全球唯一的身份证，不管你在哪个服务器上执行，这个身份证都不会变。有了它，复制就变得轻松多了，不再像以前那样靠 binlog 文件名和 position 来定位，容易出错。二、AUTO_POSITION 又是啥？ AUTO_POSITION，顾名思义，就是自动定位。有了它，从库（Slave/Replica）可以自动找到主库（Master/Source）需要复制的位置，不需要你手动去指定 binlog 文件名和 position。这就像 GPS 导航一样，你只需要告诉它目的地，它自己会规划路线。三、AUTO_POSITION 的优势简化配置：不需要手动指定 binlog 文件名和 position，避免人为错误。自动容错：当主库切换时，从库可以自动找到新的主库继续复制 …

继续阅读“MySQL高级讲座篇之：如何利用`GTID`的`AUTO_POSITION`功能，实现无损故障切换？”

2025年8月17日

MySQL高级讲座篇之：`TiDB`和`MySQL`的异同：从分布式事务、可扩展性到生态系统。

各位好，我是老张，今天咱们来聊聊两个数据库界的扛把子：MySQL 和 TiDB。别看它们名字里都有个“DB”，看起来像亲兄弟，但实际上，它们在骨子里可是大相径庭。今天老张就带着大家一起扒一扒它们的异同，从分布式事务、可扩展性到生态系统，保证让大家听完之后，对这两个数据库有一个更深刻的理解。第一回合：身世背景大揭秘 MySQL，这个老牌关系型数据库，江湖地位那是杠杠的。它是单机数据库的代表，经历了几十年的发展，生态系统非常完善，各种工具、框架应有尽有。 TiDB，则是一位后起之秀，是NewSQL数据库的典型代表。它是由 PingCAP 公司开发的，目标是打造一个兼容 MySQL 协议的、具有分布式事务、水平扩展能力的数据库。简单来说，TiDB 就是想在保持 MySQL 使用习惯的同时，解决 MySQL 在大数据量、高并发场景下的瓶颈。第二回合：分布式事务，谁更胜一筹？事务，是数据库的核心概念。所谓事务，就是一系列操作，要么全部成功，要么全部失败。在单机数据库中，事务的 ACID 特性（原子性、一致性、隔离性、持久性）很容易保证。但是，在分布式数据库中，保证事务的 A …

继续阅读“MySQL高级讲座篇之：`TiDB`和`MySQL`的异同：从分布式事务、可扩展性到生态系统。”

2025年8月17日

MySQL高级讲座篇之：如何设计一个基于`Galera Cluster`的无单点故障集群？

各位观众老爷们，晚上好！我是你们今晚的MySQL讲师，咱们今天不聊源码八卦，专啃硬骨头，聊聊如何打造一个坚如磐石，刀枪不入，没了谁地球都照常转的MySQL Galera Cluster 集群。先说清楚，今天讲的是“无单点故障”，不是绝对意义上的“永生不死”。毕竟，理论上讲，太阳系毁灭了，集群也得跟着凉凉。但在可接受的范围内，我们要让这个集群尽可能皮实，能扛住各种突发情况。一、Galera Cluster 是个什么玩意儿？ Galera Cluster 简单来说，就是一个多主复制（Multi-Master Replication）的解决方案。传统的MySQL主从复制，主挂了，就得手动切换，费时费力。 Galera不一样，每个节点都可以读写，数据实时同步，某个节点挂了，应用可以自动切换到其他节点，基本无感。想象一下：你有三台服务器，分别叫 node1, node2, node3。它们都安装了MySQL，并且组成了Galera Cluster。你往node1里插入一条数据，这条数据会立刻同步到node2和node3。如果node1突然宕机了，你的应用可以立刻连接到node2 …

继续阅读“MySQL高级讲座篇之：如何设计一个基于`Galera Cluster`的无单点故障集群？”

2025年8月17日

MySQL高级讲座篇之：探讨MySQL`5.7`和`8.0`主从复制的性能优化与架构演进。

嘿，大家好！我是老码农，今天咱们聊聊MySQL主从复制，尤其是5.7和8.0这两个版本，在性能优化和架构演进上的一些门道。保证让大家听得明白，用得上，还能时不时会心一笑。开场白：复制，数据库的“影分身术” 话说，单机数据库再牛，也怕扛不住高并发，更怕万一宕机。怎么办？那就得靠复制，让数据有多份备份，就像鸣人的影分身术一样。MySQL的主从复制，就是干这个的。第一回合：5.7时代的挣扎 MySQL 5.7的主从复制，虽然已经很成熟了，但还是有些“老年病”。咱们先来看看它的基本架构： Master (主库): 负责写入数据，并将变更记录到二进制日志 (Binary Log，简称Binlog)。 Slave (从库): 从Master拉取Binlog，然后在本地重放这些变更，保持数据同步。 Relay Log (中继日志): Slave从Master拉取的Binlog，先存放在Relay Log中，然后再执行。 7的复制架构，简单来说就是：主库写，从库读，中间靠Binlog传递消息。 5.7的性能瓶颈与优化 7的复制，经常会遇到以下问题：单线程复制：默认情况下，Slave只有一个SQ …

继续阅读“MySQL高级讲座篇之：探讨MySQL`5.7`和`8.0`主从复制的性能优化与架构演进。”

2025年8月17日

MySQL高级讲座篇之：`Semi-Synchronous Replication`的`Wait for All Slaves`机制如何保证数据一致性？

各位观众老爷，大家好！今天咱们来聊聊MySQL半同步复制里那个“Wait for All Slaves”机制，看看它怎么保证咱们宝贵的数据不丢，不乱，稳稳当当。开场白：数据一致性，比你的工资还重要！数据这玩意儿，对咱们来说，比工资还重要！工资没了，还能再挣，数据没了，那可就麻烦大了。想象一下，银行的数据丢了，你的存款没了，那还得了？电商的数据丢了，你的订单没了，那还不得投诉到你怀疑人生？所以，数据一致性，那可是数据库的命根子！MySQL的半同步复制，就是为了保证这个命根子，而“Wait for All Slaves”机制，则是半同步复制里的一把利剑。什么是半同步复制？在聊“Wait for All Slaves”之前，咱们先简单回顾一下半同步复制。它跟异步复制最大的区别在于：异步复制：主库写完数据就OK了，直接返回给客户端，至于从库有没有收到，啥时候收到，主库压根不管。就像你给朋友发微信，你发完就完事了，至于他啥时候看，那就是他的事儿了。半同步复制：主库写完数据后，至少要等一个从库收到并确认，才返回给客户端。就像你给朋友发微信，他必须回复“收到”，你才放心。半同步 …

继续阅读“MySQL高级讲座篇之：`Semi-Synchronous Replication`的`Wait for All Slaves`机制如何保证数据一致性？”

2025年8月17日

MySQL高级讲座篇之：如何利用MySQL的`Replication Filters`进行选择性数据同步？

各位观众老爷们，大家好！我是你们的老朋友，今天咱们聊聊MySQL的Replication Filters，也就是复制过滤器，让大家伙儿也能玩转选择性数据同步，告别“复制粘贴”式的简单粗暴。开场白：复制的烦恼想象一下，你的公司壮大了，数据也跟着膨胀。你的数据库也从单枪匹马变成了集群作战。现在你有一主多从的MySQL架构，主库承载所有的读写操作，从库分担读的压力。一开始，你信心满满，觉得复制很简单，一股脑儿把主库的数据都复制到从库。但是，问题来了！数据冗余：从库不需要主库的所有数据，比如一些日志表，测试数据，或者敏感信息。网络带宽：复制所有数据占用大量网络带宽，影响其他服务的性能。存储压力：从库的存储空间有限，全部复制可能导致存储空间不足。性能瓶颈：从库复制大量无用数据，降低查询效率，影响读的性能。所以，我们需要一种更优雅的方式，只复制我们需要的数据。这就是Replication Filters大显身手的时候了。 Replication Filters：你的数据剪刀手 Replication Filters就像一把精密的剪刀，可以让你选择性地复制数据。你可以指定哪些 …

继续阅读“MySQL高级讲座篇之：如何利用MySQL的`Replication Filters`进行选择性数据同步？”

2025年8月17日

MySQL高级讲座篇之：`Sharding`在MySQL集群中的自动化：`MySQL Router`和`ProxySQL`的应用。

各位靓仔靓女，晚上好！我是你们今晚的MySQL特约讲师，人送外号“Bug终结者”。今天咱们来聊聊MySQL集群的“分身术”——Sharding，以及如何让这些“分身”听话地干活，也就是Sharding的自动化。这次的重点是MySQL Router和ProxySQL这两个神器，它们能让你的Sharding集群管理起来像喝水一样轻松。准备好了吗？咱们开车了！一、Sharding：集群界的“孙悟空” Sharding，中文名叫“分片”，简单来说就是把一个庞大的数据库拆分成多个小数据库，每个小数据库都只负责一部分数据。这就好比把一个巨无霸汉堡切成几块，分给不同的人吃，每个人压力都小了，整体效率自然就提高了。为什么要Sharding？数据量太大：单个数据库hold不住了，撑爆了！并发太高：数据库服务器累吐血了，扛不住了！性能瓶颈：读写速度慢如蜗牛，用户体验极差！ Sharding的类型垂直分片 (Vertical Sharding): 按照业务功能拆分。比如，用户表、订单表、商品表分别放在不同的数据库。水平分片 (Horizontal Sharding): 按照某种规则（例 …

继续阅读“MySQL高级讲座篇之：`Sharding`在MySQL集群中的自动化：`MySQL Router`和`ProxySQL`的应用。”