Golang 调度器原理分析

本文是 Golang 调度器原理分析。 参考资料 http://tonybai.com/2017/06/23/an-intro-about-goroutine-scheduler/ https://www.zhihu.com/question/20862617?rf=45525005 茶歇驿站 一个可以让你停下来看一看,在茶歇之余给你帮助的小站,这里的内容主要是后端技术,个人管理,团队管理

sync.Once 源码分析

本文是sync.Once的源码分析。 源码很少,直接看源码吧。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 // Copyright 2009 The

interface 与 nil 的那些坑

本文是我们在使用 interface 以及跟nil处理时的一些坑。 未完待续。。。 茶歇驿站 一个可以让你停下来看一看,在茶歇之余给你帮助的小站,这里的内容主要是后端

负载均衡

本文是我对负载均衡的一些理解和总结。 负载平衡(Load balancing)是一种计算机网络技术,用来在多个计算机(计算机集群)、网络连接、C

TiDB 和 MySQL 的索引实践

本文是我在比对 MySQL 和 TiDB 使用索引以及执行计划的一些总结,希望能够给大家带来帮助。

提前准备

上文 MySQL 的索引优化实践 中,我对 MySQL 的索引优化有了一定的概述,今天再针对 TiDB 的索引进行一些实战。

pt 表:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
CREATE TABLE `pt` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `data` longtext COMMENT '内容',
  `next_at` bigint(20) DEFAULT NULL COMMENT '下次时间',
  `update_at` int(11) NOT NULL COMMENT '更新时间',
  `created_at` int(11) NOT NULL COMMENT '创建时间',
  `deleted` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0未删除 1已删除',
  `invalid` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0正常 1作废',
  PRIMARY KEY (`id`),
  KEY `idx_next_at` (`next_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='pt表';

MySQL 和 TiDB 的 pt 表有 35 万行数据。

MySQL 的执行计划如下:

1
explain select * from pt where deleted=0 and invalid=0 and next_at<=15100004 ;

结果如图:

TiDB 的执行计划结果如图:

从上面的执行计划结果来看,两者的方式是不一样的。

至于到底是什么不一样呢?我猜想是因为他们对于索引的实现是完全不一样的,这个比较复杂,今天就不做阐述了,后面有时间再来探究吧。

MySQL 的索引优化实践

本文是我在使用 MySQL 过程中遇到的 SQL 查询导致的大量慢查询语句的索引优化实践总结,希望能够给大家带来帮助。

多数情况下,我们知道索引能够提高查询效率,但应该如何建立索引?索引的顺序如何?许多人却只知道大概。其实要理解这些概念并不难,而且索引的原理远没有想象的那么复杂。

提前准备

pt 表:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
CREATE TABLE `pt` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `data` longtext COMMENT '内容',
  `next_at` bigint(20) DEFAULT NULL COMMENT '下次时间',
  `update_at` int(11) NOT NULL COMMENT '更新时间',
  `created_at` int(11) NOT NULL COMMENT '创建时间',
  `deleted` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0未删除 1已删除',
  `invalid` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0正常 1作废',
  PRIMARY KEY (`id`),
  KEY `idx_next_at` (`next_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='pt表';

假如 pt 表有数据量 800 万,查询 SQL 语句及执行计划如下:

1
2
explain SELECT id FROM pt WHERE next_at <= 1514822400 AND deleted=0 AND invalid=0
1  SIMPLE  pt   NULL    ALL idx_next_at NULL    NULL    NULL    7843117 0.00    Using where

从上面的 SQL 执行计划可以很明显看出来是用到了索引,但是扫描的数据行有 784 万之多,基本上是全表扫描了,但是其实 SQL 语句本身的查询结果数据只有 3 万多行的。

解决Git fatal错误提示

本文是在 git push 数据时遇到的一个问题解决方法。

情景再现

错误信息:fatal: refusing to merge unrelated histories

我给大家还原一下以上错误,并且再来介绍一下如何解决并成功提交数据的。

  1. 你在本地新建一个项目jaeger-opentracing-examples
  2. 给这个项目添加一些数据;
  3. 执行 git add ., git commit -m "init"
  4. 在执行 git push origin master 之前,还需要执行git remote add origin https://github.com/yangwenmai/jaeger-opentracing-examples.git
  5. 执行 git pull origin master
  6. fatal: refusing to merge unrelated histories

这个问题,其实我以前也遇到过,但是以前是怎么解决的呢?

直接本地文件重命名,然后再从 GitHub 拉取项目,然后把本地项目的所有文件拷贝到拉取到的项目文件中,然后再提交数据并推上去。

这虽然是一种解决办法,也不无伤大雅,但是这个办法终归不是正统的解决之道,本着学习和专研的精神,不应该逃避问题的方式来达到解决问题,所以我 Google 了。

在MySQL PROCESSLIST中的 statistics 是什么?

本文是线上MySQL数据库问题的排查总结,希望能够对大家有所帮助。

statistics

线上服务出现大量的服务告警,怀疑是 MySQL 数据库的问题,查看监控发现有大量SQL慢查询,查询processlist,发现很多状态是 statistics。

processlist里面有好几个长时间处于 statistics 状态的线程,表示正在计算统计数据,以制定一个查询执行计划。 如果一个线程处于这种状态很长一段时间,可能是磁盘IO性能很差,或者磁盘在执行其他工作。

如何在MySQL里面执行表碎片优化?

本文给大家介绍当你的表有大量DELETE的时候,产生的表锁片如何清理,希望能够对大家有所帮助。

当我们在执行了 delete from table_name 之后会有大量的碎片空间占用,那我们应该怎么去释放呢?

如果你的 MySQL 存储引擎是 MyISAM ,那么直接执行 optimize table table_name;即可。

如果你的存储引擎是 InnoDB ,执行 optimize table table_name ,会有可能出现两行结果: 第一行: Table does not support optimize, doing recreate + analyze instead 第二行 OK

那到底有没有成功呢?其实是成功释放了表碎片空间的。

但是有提示 Table 不支持 optimize 怎么办呢?

其实对于 InnoDB 来说,要释放表锁片空间,我们可以采用 alter table table_name ENGINE=InnoDB

不管是 optimize 还是 alter table 都是会锁表的,我们在操作的时候要特别注意,要选择在表变更/使用的低峰期进行操作,否则会导致大量的锁表。

解释:ALTER table table_name 其实是一个空操作,类似于重建表,可以把旧的缓存以及表的碎片空间都释放掉。

虽然 optimize table table_name 也能够释放表锁片空间,但是我们还是建议使用 ALTER TABLE table_name ENGINE=InnoDB;