August 16, 2018
MySQL 5.6新特性MRR
"**一、什么是MRR ** MMR全称是Multi-Range Read,是MYSQL5.6优化器的一个新特性,在MariaDB5.5也有这个特性。优化的功能在使用二级索引做范围扫描的过程中减少磁盘随机IO和减少主键索引的访问次数。是优化器将随机 IO 转化为顺序 IO 以降低查询过程中 IO 开销的一种手段。(参考: https://blog.csdn.net/caomiao2006/article/details/52205177)\n**二、MRR和没有MRR的区别 ** 给出一个简单的例子,在innodb表执行下面的查询:\nSELECT non_key_column FROM tbl WHERE key_column=x\n在没有MRR的情况下,它是这样得到结果的:\n1. select key_column, pk_column from tb where key_column=x order by key_column —\u0026gt; 假设这个结果集是t\n2. for each row in t ; select non_key_column from tb where …"
August 4, 2018
MySQL中select中的for update 的用法
"注意: FOR UPDATE 只能用在事务区块(BEGIN/COMMIT)中才有效。 有时候我们会看到一些select语句后面紧跟一句for update,表示手动加锁的意思,这里我们就介绍一下对for update的理解。相对另一种手动加锁方法lock in share mode 的区别见: https://blog.csdn.net/liangzhonglin/article/details/65438777。\nfor update:IX锁(意向排它锁),即在符合条件的rows上都加了排它锁,其他session也就无法在这些记录上添加任何的S锁或X锁。如果不存在一致性非锁定读的话,那么其他session是无法读取和修改这些记录的,但是innodb有非锁定读(快照读并不需要加锁),for update之后并不会阻塞其他session的快照读取操作,除了select …lock in share mode和select … for update这种显示加锁的查询操作。\nlock in share mode:是IS锁(意向共享锁),即在符合条件的rows上都加了共享锁,这样的话,其 …"
August 4, 2018
mysql explain 中key_len的计算方法
"建议先阅读这篇文章: http://hidba.org/?p=404\n下面我们只对其中提到的做一个验证。\n(1).索引字段的附加信息:可以分为变长和定长数据类型讨论,当索引字段为定长数据类型,比如char,int,datetime,需要有是否为空的标记,这个标记需要占用1个字节;对于变长数据类型,比如:varchar,除了是否为空的标记外,还需要有长度信息,需要占用2个字节;\n(备注:当字段定义为非空的时候,是否为空的标记将不占用字节)\n(2).同时还需要考虑表所使用的字符集,不同的字符集,gbk编码的为一个字符2个字节,utf8编码的一个字符3个字节, utf8mb4 编码则是4个字节;\n每种MySQL数据类型的定义参考:\n下面我们以定长数据类型准,变长数据类型请自行测试。\n一、数据索引类型允许为null的情况:\n表结构:\nCREATE TABLE `tb` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `sid` smallint(5) DEFAULT NULL, `gid` smallint(5) DEFAULT NULL, …"
August 3, 2018
redis list数据类型 不同编码ziplist 和 linkedlist的区别
"https://my.oschina.net/justfairytale/blog/393830"
August 1, 2018
Redis单线程架构
"1 单线程模型 Redis客户端对服务端的每次调用都经历了发送命令,执行命令,返回结果三个过程。其中执行命令阶段,由于Redis是单线程来处理命令的,所有每一条到达服务端的命令不会立刻执行,所有的命令都会进入一个队列中,然后逐个被执行。并且多个客户端发送的命令的执行顺序是不确定的。但是可以确定的是不会有两条命令被同时执行,不会产生并发问题,这就是Redis的单线程基本模型。\n2 单线程模型每秒万级别处理能力的原因 (1)纯内存访问。数据存放在内存中,内存的响应时间大约是100纳秒,这是Redis每秒万亿级别访问的重要基础。\n(2)非阻塞I/O,Redis采用epoll做为I/O多路复用技术的实现,再加上Redis自身的事件处理模型将epoll中的连接,读写,关闭都转换为了时间,不在I/O上浪费过多的时间。\n(3)单线程避免了线程切换和竞态产生的消耗。\n(4)Redis采用单线程模型,每条命令执行如果占用大量时间,会造成其他线程阻塞,对于Redis这种高性能服务是致命的,所以Redis是面向高速执行的数据库。\nredis为什么要设计成单线程: …"
August 1, 2018
Redis中的锁
"单Redis实例锁: http://www.redis.cn/commands/setnx.html\n分布式锁: http://redis.cn/topics/distlock.html(提供各种开发语言提供的库)"
July 30, 2018
MYSQL之ICP、MRR、BKA
"Index Condition Pushdown(ICP) Index Condition Pushdown (ICP)是mysql使用索引从表中检索行数据的一种优化方式。\nICP原理 禁用ICP,存储引擎会通过遍历索引定位基表中的行,然后返回给MySQL Server层,再去为这些数据行进行WHERE后的条件的过滤。\n开启ICP,如果部分WHERE条件能使用索引中的字段,MySQL Server 会把这部分下推到存储引擎层,存储引擎通过索引过滤,把满足的行从表中读取出。ICP能减少引擎层访问基表的次数和MySQL Server 访问存储引擎的次数。\nICP的目标是减少从基表中全纪录读取操作的数量,从而降低IO操作\n对于InnoDB表,ICP只适用于辅助索引。\nICP标识 当使用ICP优化时,执行计划的Extra列显示Using indexcondition提示\n相关参数 optimizer_switch=\u0026#34;index_condition_pushdown=on”; 适用场景 #辅助索引INDEX (zipcode, lastname, firstname).\nSELECT * …"
July 10, 2018
PHP连接mysql8.0出错“SQLSTATE[HY000] [2054] The server requested authentication method unknown to”的解决办法
"错误信息\nSQLSTATE[HY000] [2054] The server requested authentication method unknown to…\n这个错可能是mysql默认使用 caching_sha2_password 作为默认的身份验证插件,而不再是 mysql_native_password,但是客户端暂时不支持这个插件导致的。 官方文档说明\nIn MySQL 8.0, caching_sha2_password is the default authentication plugin rather than mysql_native_password. For information about the implications of this change for server operation and compatibility of the server with clients and connectors, see caching_sha2_password as the Preferred Authentication Plugin.\n …"
July 10, 2018
使用Dockerfile构建Swoole+php7环境
"FROM php:7.2.7-cli RUN apt-get update \u0026amp;\u0026amp; apt-get install -y libmemcached-dev zlib1g-dev RUN pecl install redis-4.0.1 \u0026amp;\u0026amp; pecl install swoole-4.0.1 \u0026amp;\u0026amp; pecl install memcached-3.0.4 \u0026amp;\u0026amp; pecl install xdebug-2.6.0 \u0026amp;\u0026amp; docker-php-ext- enable redis swoole memcached xdebug COPY . /usr/src/myapp WORKDIR /usr/src/myapp CMD [ \u0026#34;php\u0026#34;, \u0026#34;-m\u0026#34; ] 构建完环境后,使用方法见: https://blog.haohtml.com/archives/17925 …"
July 6, 2018
MySQL中的查询开销查看方法
"MySQL使用基于 成本的优化器,它尝试预测一个查询使用某种执行计划时的成本,并选择其中成本最小的一个。在MySQL可以通过查询当前会话的 last_query_cost 的值来得到其计算当前查询的成本。\nmysql\u0026gt; select * from t_message limit 10; ...省略结果集 mysql\u0026gt; show status like \u0026#39;last_query_cost\u0026#39; +-----------------+-------------+ | Variable_name | Value | +-----------------+-------------+ | Last_query_cost| 6391.799000 | +-----------------+-------------+ 示例中的结果表示优化器认为大概需要做6391个数据页的随机查找才能完成上面的查询。这个结果是根据一些列的统计信息计算得来的,这些统计信息包括: 每张表或者索引的页面个数、 索引的基数、 索引 和 数据行的长度、 索引的分布 情况等等。\n有非常多的原因会导 …"