日志切割 logrotate 之 copytruncate

本文是对于 logrotate 日志切割的一点点小总结。 我们在使用 logkit 上报 Nginx 日志数据的时候,发现被切割之后,无法正常上传了。 我们的 logrotate 配置使用的是 copytrunc

Golang GC 原理分析

本文是 Golang GC 原理分析。 参考资料 https://gocn.io/article/192 https://lengzzz.com/note/gc-in-golang https://www.zhihu.com/question/58863427 茶歇驿站 一个可以让你停下来看一看,在茶歇之余给你帮助的小站,这里的内容主要是后端技术,个人管理,团队管理,

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 的执行计划结果如图:

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

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