Mark's Blog

Mysql Join我们 DBA 不让使用 join，使用 join 有什么问题呢？如果有两个大小不同的表做 join，应该用哪个表做驱动表呢？ Index Nested-Loop Join1select * from t1 straight_join t2 on (t1.a=t2.a); 如果直接使用 join 语句，MySQL 优化器可能会选择表 t1 或 t2 作为驱动表，这样会影响我们分析 SQL 语句的执行过程。所以，为了便于分析执行过程中的性能问题，我改用 straight_join 让 MySQL 使用固定的连接方式执行查询，这样优化器只会按照我们指定的方式去 join。在这个语句里，t1 是驱动表，t2 是被驱动表。 现在，我们来看一下这条语句的 explain 结果。 可以看到，在这条语句里，被驱动表 t2 的字段 a 上有索引，join 过程用上了这个索引，因此这个语句的执行流程是这样的： 从表 t1 中读入一行数据 R； 从数据行 R 中，取出 a 字段到表 t2 里去查找； 取出表 t2 中满足条件的行，跟 R 组成一行，作为结果集的一部分； 重复执行 ...

Mysql 临时表和group by临时表临时表的特点 建表语法是 create temporary table …。 一个临时表只能被创建它的 session 访问，对其他线程不可见。所以，图中 session A 创建的临时表 t，对于 session B 就是不可见的。 临时表可以与普通表同名。 session A 内有同名的临时表和普通表的时候，show create 语句，以及增删改查语句访问的是临时表。 show tables 命令不显示临时表。 由于临时表只能被创建它的 session 访问，所以在这个 session 结束的时候，会自动删除临时表。也正是由于这个特性，临时表就特别适合我们文章开头的 join 优化这种场景。为什么呢？ 原因主要包括以下两个方面： 不同 session 的临时表是可以重名的，如果有多个 session 同时执行 join 优化，不需要担心表名重复导致建表失败的问题。 不需要担心数据删除问题。如果使用普通表，在流程执行过程中客户端发生了异常断开，或者数据库发生异常重启，还需要专门来清理中间过程中生成的数据表。而临时表由于会自动回收，所以 ...

Mysql 事务（mvcc+间隙锁）事务隔离提到事务，你肯定会想到 ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性），今天我们就来说说其中 I，也就是“隔离性”。 当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题，为了解决这些问题，就有了“隔离级别”的概念。 在谈隔离级别之前，你首先要知道，你隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点。SQL 标准的事务隔离级别包括：读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（serializable ）。下面我逐一为你解释： 读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。 读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。 可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数 ...

程序员如何为女朋友做迪士尼攻略 身为一个程序员，我们每天大多时间对着计算机没有交际应酬，更不懂得浪漫与体贴。我能为女朋友做点什么呢？我是不是能用我的专业来帮女票做点事情。刚好女票生日计划去迪士尼玩，做攻略的重任就落到了我的身上。 我利用数据和逻辑科学的帮助女友生成了一份攻略，代码在这里 前言我在苦思冥想该怎么做攻略的时候看了很多小红书，视频，还有直播，我发现他们都会给出游玩攻略。但很可惜他们清一色的就是告诉你该以什么顺序去玩却不告诉你形成攻略的具体逻辑是什么，他们形成攻略的说辞基本就是靠经验，这对于我一个逻辑至上的程序员来说是不能忍受的。所有的up主都千篇一律的就是第一个冲翱翔地平线，第二个小矮人矿车。。。 我知道他们通过经验形成的逻辑点就是在最早的时间冲最火的项目，这样在主观感受上确实是可以节省更多时间。但最火的项目在早上不也一样是最火的？不也一样等的时间比其他的久，在所有项目都接近排队时长最短的黄金早晨时间项目排队耗费时间也是能否玩更多项目的关键。 我觉得可以根据多日的单项目不同时间点平均等待时间辅以一些算法来获取一个项目游玩优先级权重。 攻略思路在早8：00 - 9：00 时间 ...

深入理解 Docker 随着云计算技术的发展，容器技术应运而生，他解决了大家在本地，测试，线上等不同环境下进行构建，部署的环境不统一的蛋疼问题，随之而来的是Kubernetes、微服务架构等新技术新思想这些技术不仅将各种繁琐的构建，部署环境问题完全隔离，我们的服务也向高可用， 可拓展的方向精进。 容器是如何解决环境统一性的问题的？有是如何做到统一环境的快速复制迁移的？带着这些问题我们来深入了解些容器（Docker）。 本文章为张磊老师的《深入剖析Kuernetes》容器部分的整合 Docker 是什么容器其实是一种沙盒技术。它可以让开发者将应用程序和依赖项打包成一个可移植的容器，从而实现快速部署、可移植性和可伸缩性。Docker 技术基于 Linux 容器（LXC）技术，通过隔离应用程序和依赖项的运行环境，使得应用程序在不同的计算机环境中能够保持一致的运行效果。 所谓 Docker 镜像，其实就是一个压缩包。但是这个压缩包里的内容，比 PaaS 的应用可执行文件 + 启停脚本的组合就要丰富多了。实际上，大多数 Docker 镜像是直接由一个完整操作系统的所有文件和目录构成的，所以这个 ...

Tunny 库源码深度解读 Tunny 库是一个用于生成和管理goroutine池的Golang库，制定一个方法可以限制该方法并发量及控制生命周期。这是一个设计简单但功能强大且通用易用的库，之前我们说过 Machinery 库，该库功能当然强大的多，他支持分布式且支持不同任务的编排，Tunny就没有这种功能，但Tunny库异常简单轻量如果不是大型的事件推动型项目，那么Tunny就足够支持其场景。 本文解读一下Tunny库的源码并且对比 Machinery 库来总结下两位作者在设计通用场景功能时的不同思路。 源码解读架构我们先来看看Tunny 库的大体架构： 主体pool：123456789101112// Pool is a struct that manages a collection of workers, each with their own// goroutine. The Pool can initialize, expand, compress and close the workers,// as well as processing jobs with the w ...

Go 语言使用定时调度任务大杀器 — XXL-JOB XXL-JOB 是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。 本文将以一个 gopher 的视角教你跳过 java 环境，做到仅仅使用 golang 也可以开箱即用，玩转 XXL-JOB。 XXL-JOB 使用文档 为什么要用XXL- JOB 在我看来可以替代我们系统中所有定时任务调度，因为定时任务的不可掌控，尤其是在分布式集群中。如果一个任务失败了那么我们首先无法即时发现，其次我们就算发现了也没法去重新触发他来解决问题，解决问题只能靠重启服务，但有的服务又不能随便重启，打个比方：行情服务，他一直在不断的接收数据流，重启势必造成数据丢失，丢失都还是好的重启服务还会造成数据堆积，消息队列阻塞，数据更新延迟，所以一旦这种服务的定时任务出现问题你只有任他发展。这个时候 XXL- JOB 这个应用就成了解决问题的大杀器。 定时及手动调度支持 它帮你承担了调度的任务，支持 cron 方式定义任务的定时调度，同时支持手动出发任务。 多种任务注册模式 主 ...

Mysql 索引InnoDB 的索引模型在 InnoDB 中，表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为索引组织表。又因为前面我们提到的，InnoDB 使用了 B+ 树索引模型，所以数据都是存储在 B+ 树中的。 每一个索引在 InnoDB 里面对应一棵 B+ 树 根据叶子节点的内容，索引类型分为主键索引和非主键索引。 主键索引的叶子节点存的是整行数据。在 InnoDB 里，主键索引也被称为聚簇索引（clustered index）。 非主键索引的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引（secondary index）。 如果语句是 select * from T where ID=500，即主键查询方式，则只需要搜索 ID 这棵 B+ 树； 如果语句是 select * from T where k=5，即普通索引查询方式，则需要先搜索 k 索引树，得到 ID 的值为 500，再到 ID 索引树搜索一次。这个过程称为回表。 也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。 索引维护B+ 树为 ...

Mysql 锁根据加锁的范围，MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类 全局锁顾名思义，全局锁就是对整个数据库实例加锁。MySQL 提供了一个加全局读锁的方法，命令是 Flush tables with read lock (FTWRL)。当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。 全局锁的典型使用场景是，做全库逻辑备份。也就是把整库每个表都 select 出来存成文本。 以前有一种做法，是通过 FTWRL 确保不会有其他线程对数据库做更新，然后对整个库做备份。注意，在备份过程中整个库完全处于只读状态。 但是让整库都只读，听上去就很危险： 如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆； 如果你在从库上备份，那么备份期间从库不能执行主库同步过来的 binlog，会导致主从延迟。 其实是有一个方法能够拿到一致性视图的，对吧？ 就是在可重复读隔离级别下开启一个事务。 官方自带的逻辑备份工具是 mysqldump。当 ...

Mysql 排序Order by在你开发应用的时候，一定会经常碰到需要根据指定的字段排序来显示结果的需求。还是以我们前面举例用过的市民表为例，假设你要查询城市是“杭州”的所有人名字，并且按照姓名排序返回前 1000 个人的姓名、年龄。 1select city,name,age from t where city='杭州' order by name limit 1000 ; 全字段排序前面我们介绍过索引，所以你现在就很清楚了，为避免全表扫描，我们需要在 city 字段加上索引。在 city 字段上创建索引之后，我们用 explain 命令来看看这个语句的执行情况。 Extra 这个字段中的“Using filesort”表示的就是需要排序，MySQL 会给每个线程分配一块内存用于排序，称为 sort_buffer。 通常情况下，这个语句执行流程如下所示 ： 初始化 sort_buffer，确定放入 name、city、age 这三个字段； 从索引 city 找到第一个满足 city=’杭州’条件的主键 id，也就是图中的 ID_X； 到主键 id 索引取出 ...