2017年5月

2017
05-28

mysql中count(x)到底慢不慢 NEW

总结MyISAM 表不支持事务，但是count(*) 很快，因为他直接记录了一个总数MyISAM在统计表的总行数的时候会很快，但是有个大前提，不能加有任何WHERE条件。这是因为：MyISAM对于表的行数做了优化，具体做法是有一个变量存储了表的行数，如果查询条件没有WHERE条件则是查询表中一共有多少条数据，MyISAM可以做到迅速返回，所以也解释了如果加WHERE条件，则该优化就不起作用了。细心的同学会发现，innodb的表也有这么一个存储了表行数的变量，但是很遗憾这个值是... Read More >

2017
05-26

redis scan命令的count参数 NEW

背景今天业务功能中想用sscan实现某个功能，突然发现count并不起作用，不管count 传什么，都返回所有的数据127.0.0.1:6379[13]> sSCAN comment:posts_list_zset_all_20_19097 "" match "*" count 2 1) "0" 2)  1)... Read More >

2017
05-25

redis中过期数据的删除以及对性能的影响 NEW

过期数据的删除对Redis性能影响当我们对某些 key 设置了 expire 时，数据到了时间会自动删除。如果一个键过期了，它会在什么时候删除呢？下面介绍三种删除策略：定时删除    在这是键的过期时间的同时，创建一个定时器 Timer，让定时器在键过期时间来临时立即执行对过期键的删除。惰性删除    键过期后不管，每次读取该键时，判断该键是否过期... Read More >

2017
05-23

mysql中找出无用的索引或重复索引

背景MySQL允许在相同列上创建重复的索引，但这样做对数据库却是有害而无利的，需要定期检查此类重复索引以改善数据库性能。可减少磁盘空间占用、减少磁盘IO、减少优化器优化查询时需要比较的索引个数、减少数据库维护冗余索引的各类开销、提高数据库性能（插入、更新、删除）重复索引检测  pt-duplicate-key-checker：通过SHOW CREATE TABLE输出的表定义检测MySQL表中重复或者冗余的索引或外键可以检测到的冗余/重复索引类型：若某个索引和另外某... Read More >

2017
05-22

redis中底层的编码转换

编码转化Redis 使用对象（redisObject）来表示数据库中的键值，当我们在 Redis 中创建一个键值对时，至少创建两个对象，一个对象是用做键值对的键对象，另一个是键值对的值对象。例如我们执行 SET MSG XXX 时，键值对的键是一个包含了字符串“MSG”的对象，键值对的值对象是包含字符串”XXX”的对象。redisObject 的结构如下：typedef struct&n... Read More >

2017
05-21

mysql中performance_schema(三) 实践篇

背景前一篇文章我们分析了performance_schema中每个表的用途，以及主要字段的含义，比较侧重于理论的介绍。这篇文章我主要从DBA的角度出发，详细介绍如何通过performance_schema得到DBA关心的数据，比如哪个SQL执行次数最多，哪个表访问最频繁，哪个锁最热等信息。通过充分利用performance_schema表的数据，让DBA更了解DB的运行状态，也更有助于排查定位问题。本文主要从两方面展开讨论，第一方面是统计信息维度，包括SQL维度，对象维度和等... Read More >

2017
05-21

redis中压缩列表ziplist的使用

压缩列表压缩列表 ziplist 是为 Redis 节约内存而开发的，是列表键和字典键的底层实现之一。当元素个数较少时，Redis 用 ziplist 来存储数据，当元素个数超过某个值时，链表键中会把 ziplist 转化为 linkedlist，字典键中会把 ziplist 转化为 hashtable。ziplist 是由一系列特殊编码... Read More >

2017
05-20

mysql中performance_schema(二) 理论篇

背景mysql performance_schema中总共包含52个表，主要分为几类：Setup表，Instance表，Wait Event表，Stage Event表Statement Event表，Connection表和Summary表。上一篇文章已经着重讲了Setup表，这篇文章将会分别就每种类型的表做详细的描述。Instance表     instance中主要包含了5张表：cond_instances，file_instanc... Read More >

2017
05-19

redis中zset有序集合的底层实现

跳跃表Zset 是一个有序的链表结构，其底层的数据结构是跳跃表 skiplist，其结构如下：typedef struct zskiplistNode {     //成员对象    robj *obj;     //分值     //后退指针  &... Read More >

2017
05-18

mysql中performance_schema(一)配置篇

背景    performance_schema最早在MYSQL 5.5中出现，而现在5.6，5.7中performance_schema又添加了更多的监控项，统计信息也更丰富，真乃DBA童鞋进行性能诊断分析的福音。检查当前数据库版本是否支持    performance_schema被视为存储引擎。 如果该引擎可用，则应该在INFORMATION_SCHEMA.ENGINES表或SHOW ENG... Read More >

2017
05-17

redis中字典的底层实现

哈希表概述       表现为：存储位置 = f(key);       存储过程如下：根据 key 计算出它的 hash 值 h。 假设箱子的个数为 n，那么这个键值对应该放在第(h%n)个箱子中。如果该箱子中已经有了键值对，就是用开放寻址法或者拉... Read More >

2017
05-15

redis中字符串的底层实现-SDS

概述Redis 是用 C 语言开发完成的，但在 Redis 字符串中，并没有使用 C 语言中的字符串，而是用一种称为 SDS（Simple Dynamic String）的结构体来保存字符串。struct sdshdr {     int len;     int&... Read More >

2017
05-12

redis中缓存穿透与缓存雪崩缓存击穿

背景缓存系统不得不考虑的另一个问题是缓存穿透与失效时的雪崩效应。缓存穿透缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个存在的数据每次请求都要到存储层去查询，失去了缓存的意义。有 很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。一个更为简... Read More >

2017
05-10

mysql常见面试题第一讲

一、为什么用自增列作为主键1、如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引。如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引。如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。2、数据记录本身被存于主索引（一颗B+Tree）的叶子节点上，这就要求同一个叶子... Read More >

2017
05-09

mysql中行锁、两阶段锁协议、死锁以及死锁检测

行锁MySQL的行锁都是在引擎层实现的，但是 MyISAM 不支持行锁，意味着并发控制只能使用表锁，同一张表任何时刻只能被一个更新在执行，影响到业务并发度。InnoDB 是支持行锁的，这也是 MyISAM 被 InnoDB 替换的重要原因之一。行锁就是针对数据库中表的行记录的锁，这很好理解，比如事务 A 更新了一行，而这时候，事务 B 也要更新一行，则必须等事务 A 的操作完成后才能更新。两阶段锁 （Two-Phase Locking――2PL）在 InnoDB 事... Read More >

2017
05-08

mysql中长事务详解

什么是长事务运行时间比较长，长时间未提交的事务，也可以称之为大事务。这类事务往往会造成大量的阻塞和锁超时，容易造成主从延迟，要尽量避免使用长事务。下面我将演示下如何开启事务及模拟长事务：#假设我们有一张stu_tb表，结构及数据如下 stu_id 唯一索引 mysql> select * from stu_tb; +--------------+--------+----------+---------------... Read More >

2017
05-06

mysql中CPU或内存利用率过高问题

CPU 利用率过高原因在 MySQL 使用过程中，出现 CPU 利用率过高甚至超过100%时，与数据库存在低效 SQL 或大量行锁冲突有非常大的关系，一般都是由于大量低效的 SQL 导致，出现行锁冲突的概率非常低。风险若 MySQL CPU 的利用率长时间处于100%，会严重影响数据库的整体性能，极端情况下可能会出现实例 HANG 住的情况。为避免业务因 CPU 资源不足而受影响，建议提前对 CPU 利用率过高的实例进行业务优化或者升级 CPU 资源。解决方案MySQL CP... Read More >